|Col1|Col2|Col3|Col4|Col5|Col6|Col7|Col8|Col9|Col10|Col11|Col12|Col13|Col14|Col15|Col16|Col17|Col18|Col19|Col20|Col21|Col22|Col23|Col24|Col25|Col26|Col27|Col28|Col29|Col30|Col31|Col32|Col33|Col34|Col35| |---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---| |||||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||||| |||||po||||||||||||w||ar||e||||||||||||||| |||||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||||| |||||||x-||Ba||se||d|||M|||ul||||||ou||||||||||| |||||||||||||||||||||||||||||||||||| |||En||||||nm||||nt||||||||||||||||||||||| |||||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||||| |T||||nica||l Th||reat||||por||t||||||||||||||||||||| |||||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||||| # Exposing Malware in Linux-Based Multi-Cloud Environments ###### Technical Threat Report ----- ### Table of contents ###### Executive summary............................................................................................ 3 Key findings ...................................................................................................... 4 Ransomware and cryptominers........................................................................... 5 Ransomware ...................................................................................................................................... 5 Ransomware families ..................................................................................................................6 Characterizing similarity...............................................................................................................6 Characterizing behavior...............................................................................................................9 Detecting and mitigating the threat...............................................................................................10 Cryptominers...................................................................................................................................... 10 Cryptominer families....................................................................................................................10 Characterizing similarity ..............................................................................................................14 Characterizing behavior...............................................................................................................17 Detecting and mitigating the threat...............................................................................................17 Methodology....................................................................................................................................... 18 Static and dynamic analysis..........................................................................................................18 Malware datasets ........................................................................................................................18 ###### Remote access tools – Implants.......................................................................... 20 Tactics used by implants..............................................................................................................21 Attack stages..............................................................................................................................22 Attack management tools............................................................................................................23 A deeper look at Cobalt Strike – Vermilion Strike................................................................................... 23 Vermilion Strike configuration details............................................................................................24 Vermilion Strike setup..................................................................................................................26 Cobalt Strike/Vermilion Strike C2 communication..........................................................................27 Vermilion Strike Windows and Linux differences............................................................................28 Metadata....................................................................................................................................29 Vermilion Strike compatibility with Cobalt Strike team server..........................................................29 The VMware Threat Analysis Unit Cobalt Strike threat intelligence collection........................................... 30 Protocol overview and our approach.............................................................................................30 Observations since February 2020...............................................................................................32 Attribution to the specific threat actors.........................................................................................35 Identifying potential targets.........................................................................................................37 Detecting and mitigating the threat...............................................................................................38 ###### VMware recommendations................................................................................. 39 References........................................................................................................ 41 |t ... ... ... .... .... .... .... .... .... .... .... .... ....|s .. .. .. .... ... ... ... ... .... ... ... ... ...|... ... ... ... .... .... .... .... ... .... .... .... ....|... ... ... .... ... ... ... ... .... ... ... ... ...|.. .. .. ... .... .... .... .... ... .... .... .... ....|... ... ... ... ... ... ... ... ... ... ... ... ...|.. .. .. .... .... .... .... .... .... .... .... .... ....|... ... ... ... ... ... ... ... ... ... ... ... ...|... ... ... .... ... ... ... ... .... ... ... ... ...|.. .. .. ... .... .... .... .... ... .... .... .... ....|... ... ... .... ... ... ... ... .... ... ... ... ...|... ... ... ... .... .... .... .... ... .... .... .... ....|.. .. .. .... ... ... ... ... .... ... ... ... ...|... ... ... ... ... ... ... ... ... ... ... ... ...|... ... ... .... .... .... .... .... .... .... .... .... ....|.. .. .. ... ... ... ... ... ... ... ... ... ...|... ... ... .... .... .... .... .... .... .... .... .... ....|... ... ... ... ... ... ... ... ... ... ... ... ...|.. .. .. .... ... ... ... ... .... ... ... ... ...|... ... ... ... .... .... .... .... ... .... .... .... ....|... ... ... ... ... ... ... ... ... ... ... ... ...|.. .. .. .... .... .... .... .... .... .... .... .... ....|... ... ... ... ... ... ... ... ... ... ... ... ...|... ... ... .... .... .... .... .... .... .... .... .... ....|.. .. .. ... ... ... ... ... ... ... ... ... ...|... ... ... .... ... ... ... ... .... ... ... ... ...|3 4 5 5 .6 .6 .9 .10 10 .10 .14 .17 .17|Col28|Col29|Col30|Col31|Col32|Col33|Col34|Col35| |---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---| ----- In the past five years, Linux® has become the most common operating system (OS) in multi-cloud environments. It has even bypassed Windows on Microsoft Azure to power more than 78 percent of the most popular websites.[1] Malicious actors have taken notice and are increasingly targeting vulnerable Linux-based systems in multi-cloud environments to infiltrate corporate and government networks. Threat actors know that current malware countermeasures are mostly focused on addressing Windows-based threats, leaving many public and private cloud deployments vulnerable to Linux-based attacks. These public and private clouds are high-value targets for cybercriminals, providing access to critical infrastructure services and substantial computational resources. In fact, cloud infrastructures and data centers host key components, such as email servers and customer databases, that have been the target of high-profile intelligence-gathering breaches. The large-scale campaign carried out in early 2021, which targeted Exchange servers,[2] and the Cybersecurity and Infrastructure Security Agency (CISA) alert about BlackMatter,[3] which targeted the U.S. food and agriculture sector, are good examples of how attacks to vulnerable cloud infrastructure can disrupt an organization’s value-delivery pipeline. These threats take advantage of weak authentication, vulnerabilities and misconfigurations in container-based infrastructures to infiltrate the environment with remote access tools (RATs). Once the attackers have obtained a foothold in their target cloud environment, they often look to perform two types of attacks: execute ransomware or deploy cryptomining components. Organizations need to bolster their ability to identify and defend against these types of attacks. Given the distributed, dynamic and heterogeneous nature of today’s enterprise workloads and networks, organizations need to extend telemetry across the entire infrastructure—from endpoints to multi-cloud environments. This will allow organizations to better monitor traffic and identify abnormal behavior to mitigate the impact of attacks on the enterprise, while increasing overall efficiencies and reducing operational costs. This report, based on VMware’s experience with a diverse customer base, offers a comprehensive look at Linux-based malware threats to multi-cloud environments. It highlights the unique characteristics of this class of threats and provides guidance on how combining endpoint detection and response (EDR) and network detection and response (NDR) solutions can help organizations stay ahead of the threats Linux-based malware poses. ## 78% ##### of the most popular websites are powered by Linux[1 ] Linux-based malware is a fastgrowing threat to multi-cloud environments, including data centers, that must be addressed to protect an organization’s assets and operations. This report details [the research that the VMware](https://www.vmware.com/security/threat-analysis-unit-tau.html) [Threat Analysis Unit™ has done](https://www.vmware.com/security/threat-analysis-unit-tau.html) into the latest threats to Linuxbased systems, documenting key findings that can help organizations better understand and prepare to defend themselves against these rising threats. |Col1|Col2|Col3|Col4|Col5|Col6|Col7|Col8|Col9|Col10|Col11|Col12|Col13|Col14|Col15|Col16|Col17|Col18|Col19|Col20|Col21|Col22|Col23|Col24|Col25|Col26|Col27|Col28|Col29|Col30|Col31|Col32|Col33| |---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---| |||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||| |||||||E||x|e|c|u||t|i||v|e|||s|u|m||m||a|r|y||||| ||||||||||||||a d o u b v w n e g||s e a s r h o ts|||u n s y n ur a o c||||||||||||||| ----- #### Key findings ###### Linux-based systems are fast becoming an attacker’s way into high- value, multi-cloud environments. - Linux is the most common OS across multi-cloud environments.[4] - Malware targeting Linux-based systems is increasing in volume and complexity, but it is still less sophisticated than Windows threats. - There is a lack of focus on the detection of threats that target Linux-based systems, making existing tools inadequate. - The main threats in most multi-cloud environments are ransomware, cryptominers and RATs. - Existing attack characterization techniques based on static information, such as strings and APIs, are useful but easily evaded by sophisticated threats. - Defense evasion is the most common tactic used in ransomware and cryptominers. Various encryption or obfuscation techniques, such as Base64 encoding and AES-based encryption, are used by attackers to conceal code and data. ###### Ransomware is becoming more sophisticated. - Ransomware has recently evolved to target Linux host images that are used to spin workloads in virtualized environments. - Ransomware attacks against cloud deployments are targeted, not opportunistic. - Ransomware attacks against cloud environments are often combined with data exfiltration, implementing a double-extortion scheme that improves their odds of success. - The detection of sophisticated threats targeting Linux-based systems requires dynamic analysis and continuous host monitoring—capabilities that work well with the Linux kernel. Windows, its expansion to other operating systems, such as Linux, is notable. It demonstrates the desire of threat actors to use readily available remote-control tools to target as many platforms as possible. - VMware Threat Analysis Unit discovered more than 14,000 active Cobalt Strike team servers on the internet since the end of February 2020. - The most popular protocol for the Cobalt Strike beacon is HTTPS. - Close to 90 percent of the Cobalt Strike server population is version 4 or later. - The total percentage of cracked and leaked Cobalt Strike customer IDs is 56 percent. This means that more than half of the Cobalt Strike users are using illegitimately obtained versions of the commercial software. - Vermilion Strike is just the first of many malware targeting Linux-based systems that will mimic the actions of other well-known RATs to simplify an adversary’s work. |o s. clo cr hre isti nm|hi ud ea at ng en|gh sin s ts|- g|Col5|Col6|Col7|C t • • R L •|r o Cr st M M m an cr A in As|yp m yp ole ost on ost d yp T u C|t o toj n cr er c res to s x- ob|oj st ac CP yp o c om ea mi ar b alt|ac ly ki U to ry m rc ner e a S|k m ng cy jac pto on h f s a se tri|in i at cle ki cu ly ou us n d ke|g n tac s t ng rr us nd ed in s is|a e ks o at en ed th X cr ys su|tt M fo mi ta cy to at MR e te ch|ac o cu ne cks (o ol 8 ig as m a|k ne s cr fo r X fo 9 p -re in s ub|s r on yp cu M r c er lat g . iq|us o. m to s R) ry ce ed t uit|e on cu on . X pto nt li hr ou|X et rre m M m of br e s t|M izi nc ini Rig ini ari at hr|R ng ie ng is ng es. t eat|i s. th th , o o|g e e n|Col29|Col30|Col31|Col32|Col33|Col34|Col35| |---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---| ----- #### Ransomware and cryptominers The impact of a ransomware attack can range from being a nuisance (e.g., having to restore data from backups and clean up the network) to being devastating (e.g., having to pay large sums of money to regain access to key assets). Unfortunately, when talking about cloud environments, the results tend to be more on the devastating side. Recently, cybercriminals have started calculating the damage they might cause to the valuation of a company going through a financial event to make the potential impact of their attack clear and incentivize ransom payments.[5] At the same time, they’ve been honing their tactics with increasingly sophisticated techniques to target victim organizations. Large-scale ransomware attacks on cloud deployments, however, have some distinct characteristics that make them harder to spot and stop. First, ransomware attacks against cloud deployments are targeted, not opportunistic. Unlike general ransomware, which plays a numbers game (e.g., sending malicious email attachments to millions of users in hopes that some will inadvertently click and infect their systems), attacks on cloud infrastructures are more targeted and carefully planned. These attacks are designed for maximum impact. The cybercriminals make sure that their target systems have been fully compromised before starting the file encryption process. This allows them to simultaneously encrypt the whole network to inundate response resources and make incident response more difficult. Ransomware has recently evolved to target the Linux host images used to spin up workloads in virtualized environments. This new and worrisome development shows how attackers look for the most valuable assets in cloud environments to inflict the maximum damage on their target. Examples include the Defray777 ransomware family, which encrypted host images on VMware ESXi servers,[6] and the DarkSide ransomware family, which crippled Colonial Pipeline’s networks and caused a nationwide gasoline shortage in the U.S.[7] The basic profile of a ransomware attack is so popular that even non-technical people know how it works: a network is compromised, sensitive files are encrypted, and a ransom note is presented to the victim that asks for money/cryptocurrency in exchange for a decryption key that will unlock access to the files. (For a peek into what victim organizations go through, check [out the blog post, HelloKitty: The](https://blogs.vmware.com/networkvirtualization/2021/09/hellokitty-the-victims-perspective.html/) [Victim’s Perspective.[8])](https://blogs.vmware.com/networkvirtualization/2021/09/hellokitty-the-victims-perspective.html/) |Col1|Col2|Col3|Col4|Col5|Col6|Col7|Col8|Col9|Col10|Col11|Col12|Col13|Col14|Col15|Col16|Col17|Col18|Col19|Col20|Col21|Col22|Col23|Col24|Col25|Col26|Col27|Col28|Col29|Col30|Col31|Col32|Col33| |---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---| |||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||| ||||||||||||||n d h t||o a v y v|||r m o e t||||||||||||||| ----- Many ransomware attacks against cloud environments involve exfiltrating data, allowing the attacker to implement a double-extortion scheme. Essentially, the attacker uses the data they collect as leverage to incent the victim into paying the ransom. If the victim does not comply, the attacker leaks the information, making it public on the internet to damage the victim’s reputation.[9] ###### Ransomware families For this report, the VMware Threat Analysis Unit analyzed nine ransomware families that target Linux systems, characterizing their evolution and crosspollination. A brief description of the families covered is included in the sidebar. We started analyzing the different characteristics of the ransomware samples of each of these nine families by looking at the static information extracted from their ELF files. While threats can be a combination of shell scripts, Python scripts, and binaries, this report focuses on the binaries. Binaries are usually the components that carry out the file system encryption in a ransomware attack. ###### Characterizing similarity As a first step, we used telfhash[10] to characterize the code sharing among samples. The approach used by telfhash applies a locality-sensitive hashing function, namely TLSH, to the symbols contained in the ELF files. In the case of statically linked and stripped files that contain no symbols, the hashing function is applied to the target addresses of the call instructions observed in the binary code of the program. One of the advantages of telfhash is that it is architectureindependent, so it can operate on binaries compiled for different platforms, such as x86 32bit, x86 64bit, and ARM. Because of the locality-sensitive nature of TLSH, files with similar sets of symbols produce similar telfhash values. These values can be used as a similarity metric to identify closely related samples and cluster together malware families. Note that telfhash does not produce a normalized value between two fixed values (e.g., 0.0 to 1.0), but instead defines two samples as similar when their distance is below a certain number (the default is 50). Figure 1 shows the confusion matrix of the ransomware families. Lighter colors indicate samples that were more similar. Note that this graph orders the samples by time of appearance to highlight their evolution over time. REvil The REvil ransomware, also known as Sodinokibi, originally targeted Windows hosts, but released a Linux version in spring 2021.[29] Interestingly, this threat relies on the esxcli commandline tool to stop the current ESXi virtual machines (VMs). It then encrypts their on-disk images to prevent the recovery of running VMs. Recently, REvil actors have been targeted by a coordinated take-down operation[30] that may impact future variants. DarkSide The actors behind DarkSide initially distributed REvil ransomware but grew tired of sharing the profits with the REvil ransomware-as-a-service (RaaS) operator, so decided to create their own ransomware.[31] The DarkSide ransomware has been used to target a wide variety of organizations across North America and Europe. Most famously, the U.S. fuel distribution company, Colonial Pipeline, was held ransom by DarkSide, dramatically affecting gasoline distribution on the East Coast.[32] DarkSide initially targeted Windows hosts but quickly evolved to include Linux targets— and in particular, those running on ESXi servers.[33] These servers are usually targeted after the threat actors gain access to a VMware vCenter® deployment, often by means of stolen credentials. |on ext e t e a e v ni in co tic tat ati e ry|m or o i tta ic t a g t ve s ic on bin pti|en tio nc ck tim na he re of t inf o ar on|ts n en er ’s lyz ir d i he or f s ies in|in sc t t le re e ev s i r m he . a|vol he he ak pu d n olu ncl an ati ll s Bin ra|ve me vi s t ta in tio ud so on cri ar ns|e . cti he tio e r n ed mw ex pt ies om|xfil Ess m i in n.9 an an in a tr s, a w|tra en nt for so d t re act Py re ar|tin ti o p m m cro he sa ed th us e a|g ally a ati wa ss si mp fr on ua tt|da , t yin on re - de le om lly ack|ta he g , ba s o th .|, r. f e|Col16|l|Ra RE Th kn tar rel 20 rel in vir en pr VM be tak|ns vil e ow ge ea 21. ies e t tua cry ev s. en e-|o RE n te se 29 o oo l pt ent R ta do|m vil as d d a Int n t l t ma s t th ec rg w|wa ra So Wi L er he o s ch he e en et n o|re ns di nd in est e to in ir re tly ed p|fa om no ow ux in sxc p t es on co , R by era|m w ki s ve gly li he (V -d ve Ev a tio|ilie ar bi, ho rsi , t co c Ms isk ry il co n3|s e, or sts on his m urr ). im of act or 0 t|als igi , b in th ma en It t a ru or di ha|o na ut sp re nd t E he ge nn s h na t m|lly ri at - SX n s t ing av ted a|ng i o e y|Col32|Col33|Col34|Col35| |---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---| ----- |Col1|Col2|1 0 0|.0 .8 .6|Col5|Col6|Col7|Col8|Ra Bla Bla an ran act su the ve|ns ck ck ev so or re y rtic|o M M ol m s b to we al|m at att uti wa e pu re s,|wa ter er on re hin bl n su|re is of .34 d icl ot ch|fa co th In Bla y a tar as|m ns e te ck nn ge h|ilie id Da res M ou tin eal|s ere rk tin att nc g th|d Si gl er e sp car|de y, m th ec e,|th ad at ific|e e|Col23|Col24|Col25|Col26| |---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---| **Figure 1: Code similarity between ransomware samples, based on telfhash (lighter color/lower** distance corresponds to higher similarity). From the confusion matrix in Figure 1, it is clear that samples that belong to the same family have a strong telfhash similarity. This indicates that one can build an effective classification system using telfhash. However, in some cases, the similarities diminish as time passes, showing that evolution within a family might lead to new code being introduced—possibly invalidating signatures developed for early versions of a threat. From the graph, we see how DarkSide and BlackMatter samples share substantial portions of code, and that ViceSociety shares some code fragments with REvil. This accounts for the relationship between threats that have been highlighted in previous reports. To further characterize the relationships between families of ransomware, we developed a similarity measure that leverages the term frequency–inverse document frequency (TF-IDF) algorithm applied to the hashes of the strings contained in the samples. This allows us to find the strings that best characterize each family. The confusion matrix in Figure 2 is based on the cosine similarity computed over the TF-IDF values for each string in the ransomware dataset we analyzed. BlackMatter BlackMatter is considered an evolution of the DarkSide ransomware.[34] Interestingly, the actors behind BlackMatter made sure to publicly announce that they were not targeting specific verticals, such as healthcare, oil and gas, government, and critical infrastructure companies— possibly following the backlash that the Colonial Pipeline attack created, and the unwanted attention that the DarkSide operators received. Defray777 Defray ransomware is another Linux-based threat that targets ESXi VMs.[35] An interesting property of some of its samples is that it doesn’t strip or tamper with ELF binaries, which makes it easier to analyze. This ransomware family is closely related to RansomEXX[36]—to the point that sometimes the two families are considered to be variations of the same threat. ----- |Col1|Col2|Col3|1.0 0.8 0.6|Col5|Col6|Col7|Col8|Ra He Th ran no att ma vid of|ns llo e a so tor ac ke eo a|o Ki ct m ie kin rs g Wi|m tty or wa ty g of am nd|wa s b re aft CD th e. ow|re eh h er P e It s-|fa in av su ro Cy ’s ba|m d e a cc je be an se|ilie He ch es kt rp oth d t|s llo ie sfu Re un er hr|Kit ve lly d, k e ea|ty d th 20 xa t|e 77 mp|le|Col23|Col24|Col25|Col26| |---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---| **Figure 2: Similarity among ransomware samples based on TF-IDF applied to string hashes** (lighter color/lower distance corresponds to higher similarity). The use of string hashes for similarity shows that, in some cases, strings are better than telfhash to capture similarity among samples. For example, the REvil family is better characterized using this technique instead of relying on telfhash. The use of the TF-IDF algorithm over the strings in the samples provides an opportunity for the creation of YARA rules for the identification of samples. We evaluated the YARA rules generated using our corpus of ransomware samples found running on Linux-based systems against the samples in the benign dataset, and we obtained a very low 0.01 percent false positive rate. Another interesting way to characterize Linux-based ransomware threats is to look at the directories they avoid during the encryption process. For example, the /proc file system is a pseudo-file system that provides access to kernellevel information, using a file system-like interface. Attempting to encrypt the files under this directory could create an unstable system, jeopardizing the attack. The same issue is true for other directories, such as /bin, /usr/bin, and /lib, so they are explicitly avoided by ransomware targeting Linux-based systems. HelloKitty The actors behind HelloKitty ransomware have achieved notoriety after successfully attacking CD Projekt Red, the makers of the Cyberpunk 2077 video game. It’s another example of a Windows-based threat that evolved and expanded into the Linux world, targeting Linux-based systems and ESXi servers.[37] Like other samples that target ESXi VMs, HelloKitty uses the esxcli tool to stop the VMs currently running before encrypting their files. ViceSociety The actors behind ViceSociety ransomware are believed to have broken away from the HelloKitty group. Not surprisingly, their malware shows substantial similarities with the HelloKitty ransomware. This ransomware family was responsible for attacking the United Health Centers in the San Joaquin Valley in California, among other targets, which resulted in the leaking of sensitive patient records.[38] ----- We also looked at other paths that could indicate the use of specific tools as part of the attack. Most notably, the /sbin/esxcli command is used in ESXi environments to shut down existing virtual workloads so their on-disk images can be encrypted. Therefore, the presence of a reference to this tool is likely an indication of ransomware-like behavior. ###### Characterizing behavior We used CAPA[11] to detect the capabilities of the Linux-based ransomware samples. Figure 3 shows the typical behaviors detected by CAPA aligned to the MITRE ATT&CK tactics and techniques framework. As we see from Figure 3, defense evasion is the most common tactic used in the samples. We also found various encryption or obfuscation techniques, such as Base64 encoding and AES-based encryption, used by the attacks to hide their code and data. Defense Evasion::Obfuscated Files or Information - T1027.005, 59.1% (220) Discovery::System Information Discovery - T1082, 18.0% (67) Defense Evasion::Deobfuscate/Decode Files or Information - T1140, 10.8% (40) GonnaCry GonnaCry is an open source ransomware sample written in C and Python.[40] While the Python version is mostly used as a way to showcase some of the behaviors associated with ransomware, the C version has actually been observed in the wild. eCh0raix eCh0raix ransomware targets QNAP network-attached storage (NAS) devices with weak credentials.[41] This family is written in the Go language, and its features are simpler than other ransomware families. For example, it appears that this threat does not have a way to distinguish among victims.[42] |cat l ork a th s wo se, s o h ens 027|e t i c lo re e det rk d i uc id e E .00|he o ad fer Lin ec . n h e t vas 5,|u mm s s en ux te As the as he ion 59.|se a o t ce -b d w s Ba ir ::O 1%|of nd he to as by e s am se co bfu (22|sp is ir t ed C ee pl 64 de scat 0)|e us on his ra AP fr es e a ed|cifi ed -d to ns A om . nc nd File|c t in isk ol o ali F We od d s o|oo E i is mw gn ig al in ata r In|ls SX ma lik ar ed ur so g a . for|as i ge ely e to e 3 fo n mat|pa s a t, un d ion|rt n he d|Col16|i|Ra Er Er ra tar ev Lin un na the the nt so ra|ns eb eb ns ge olv ux iq tur r ir er me ns|o us us om te ed v ue e. an ac est b om|m is w d i ari be W so tiv in eh w|wa a are Wi n 2 an ca hi m ity g s av are|re rel f nd 01 t.3 us le wa, i a io f|fa ati am o 6 9 T e th re t is mp rs am|m ve ily ws to hi of e a ha s le wi ili|ilie ly . I ho in s t its ct ve till th th es.|s ol t in st clu hr m or s an at ot|de iti s de ea ul s b to sh he|r all bu a t is tili eh pp ar r|y t ng in ed es|ua d|l|Col33|Col34|Col35| |---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---| (A) (B) Discovery::File and Directory Discovery - T1083, 8.1% (30) Execution::Shared Modules - T1129, 1.6% (6) Discovery::System Network Configuration Discovery - T1016, 1.3% (5) Defense Evasion::Virtualization/Sandbox Evasion T1497.001, 1.1% (4) base64, 25.0% (55) aes, 22.3% (49) xor, 20.5% (45) rc4 prga, 17.7% (39) sosemanuk, 7.3% (16) salsa20 or chacha, 3.6% (8) stackstrings, 3.6% (8) **Figure 3: Malicious behaviors of the ransomware samples in the dataset: (A) Typical MITRE** ATT&CK tactics and techniques leveraged by the samples; (B) Various encryption/obfuscation techniques used for defense evasion. ----- ###### Detecting and mitigating the threat The solution to the ransomware threat is a combination of approaches, mechanisms and policies. Beyond having a solid data backup and recovery process, deploying an EDR solution that monitors the actions performed by processes on cloud workloads is critical to a defense-in-depth strategy. This must be complemented by an effective segmentation and NDR system that can recognize network-based evidence of attacks and ideally block the malware before it can take hold of the target hosts. ###### Cryptominers Cybercriminals are not indifferent to the frenzy surrounding cryptocurrencies. The advantage of targeting cryptocurrencies is that successful attacks can be immediately and directly turned into cyber cash. Cybercriminals get instant reward without the need to perform cumbersome scams using stolen information, such as personal data, or by having to interact with victims of ransomware.[12] Attacks targeting cryptocurrencies typically take one of two approaches. The first is to include wallet-stealing functionality in malware, sometimes posing as cryptocurrency-based applications.[13] The second is to monetize stolen CPU cycles to successfully mine cryptocurrencies, sometimes called cryptojacking. One of the first cryptojacking attacks was against Tesla’s public cloud[14]—a Kubernetes deployment was hijacked and dedicated to mining the currency, while the computational costs were paid by Tesla. This notorious event was just the first in a series of incidents that targeted the CPU cycles of cloud environments. A report from Palo Alto Networks[15] indicated that cryptojacking affected “at least 23 percent of organizations that maintain cloud infrastructures.” Monero is the coin of the realm Most cryptojacking attacks focus on mining the Monero currency, also known as XMR. Monero is an attractive target because it is known for preserving the privacy of its users, thanks to its use of Ring Confidential Transactions (RingCT), which hides the amount of each transaction, and stealth addresses that make transactions much more difficult to trace.[16] Another driver behind the popularity of Monero among cryptojacking operators is the fact that it can be mined without needing specialized hardware. This differs from mining Bitcoin, which requires specific hardware, such as application-specific integrated circuits (ASICs), that can cost thousands of dollars.[17] With Monero, cryptominers can simply use the CPU or GPU cycles of ordinary computers, making compromised cloud workloads suitable for mining this cybercurrency. Sysrv Sysrv is a botnet written in Go with cryptomining capabilities[44] that has been recently deployed against Kubernetes pods running WordPress.[45] The actors behind Sysrv rely on shell scripts to obtain persistency and hide the presence of the miner (e.g., by providing a modified version of the top command that doesn’t show the CPUhungry processes). This threat has also worm-like capabilities, attempting to spread to different hosts by leveraging SSH keys found on compromised hosts, performing password dictionary attacks against vulnerable services, and using an everincreasing database of exploits against known remote code execution (RCE) vulnerabilities. |mb olid ito ef en a s t s h. ms|in d rs en tat nd urr uc Cy u|ati at th se io id ou ce be sin|on a b e a -in n a ea nd ssf rc g|o ac ct -d nd lly in ul rim sto|f a ku ion ep N bl g c att in le|pp p s th D oc ry ac al n i|ro an pe st R s k t pt ks s g nfo|ac d rfo rat ys he oc ca et rm|he rec rm eg te m urr n in at|s, ov e y. m al en be sta io|er d b T th wa cie nt n,|y y his at re s. re su|ca Th wa ch|n e rd as|Col16|Col17|Cr XM XM av ma a t co as to oft cry pr ca sp|yp R Ri ail c hr mp pa pe en pt efe n b eci|to ig g4 abl OS eat o rt rfo u oc rr e ali|m 3 is e f . W b ne of rm se ur ed mi ze|in a or h y i nt cr t d t re ta ne d|er n o W ile tse is yp he o ncy rg d har|fa p in th lf, oft toj m min , et wit d|mi en do is a en ac ini e wh be ho wa|lie so ws mi va d kin ng th ich ca ut re.|s ur , L ne ria ep g . X e is us n|ce in r is nt loy att M Mo th e i ee|m ux n of ed ac Ri ne e t din|in an ot thi ks g i ro g|er d s s|Col32|Col33|Col34|Col35| |---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---| ----- XMRig The most common application used to mine Monero currency is the open source XMRig miner.[18] This popular application can mine different types of cryptocurrencies, but it’s mostly used to mine Monero. Many of the cryptomining samples from Linux-based systems have some relationship to the XMRig application. Therefore, when XMRig-specific libraries and modules in Linux binaries are identified, it is likely evidence of potential cryptomining behavior. If a binary is dynamically linked and not stripped, the task of identifying XMRigrelated libraries and modules is trivial. However, stripped, statically linked binaries are challenging to analyze. In Table 1, we noted that all the cryptominers in our dataset are stripped. As a result, we needed to use function signature models, such as the ones produced by FLIRT,[19] to identify known libraries in C/C++ binaries, and tools, such as redress[20] to identify relevant modules in Go binaries. We developed FLIRT signatures for the libraries used by XMRig when compiled on various Linux distributions. We also developed Go module detectors to identify relevant crypto-related modules. When we checked for the presence of these components (written in both C/C++ and Go), we found that 89 percent of cryptomining attacks used XMRig-related libraries. None of the benign Linux binaries linked those components, making the presence of these libraries and modules an effective way to identify cryptomining behavior. Mining pools When a cryptomining program is deployed on a compromised host, the program connects to a mining pool. By joining a mining pool, the malware can contribute to the overall mining process and share the benefits of collective mining—the computing power of a single host would likely be insufficient to achieve any meaningful results. Some common, well-known mining pools are minexmr[.]com, nanopool[.]com, and supportxmr[.]com. Mexalz Mexalz threat actors are likely [based in Romania,[48] exploiting](https://www.bitdefender.com/blog/labs/how-we-tracked-a-threat-group-running-an-active-cryptojacking-campaign) weak credentials to compromise hosts and deploy cryptomining malware, which is mostly customized versions of XMRig.[49] The name of this threat is derived from the host that they use to store the components of the attacks, mexalz[.]us. ## 89% ##### of cryptomining attacks used XMRig-related libraries |Mo n M e r lib pot ed, r, d t o u tify y r ies|ne ca on el rar en th str ha se k ele u|ro n m er ati ie tia e t ip t a fu no va se|cu in o. on s a l c as pe ll t nc wn nt d b|rr e M sh nd ry k d, he tio li m y|en dif an ip m pt of i sta cr n s bra od XM|cy fer y to od om de tic yp ig rie ul R|is en of t th ul in nt all to na s es ig|th t t he e X es in ifyi y l mi tur in in wh|e o yp c M in g b ng ink ne e C/ Go e|p es ry Ri Li eh X e rs mo C+ b n c|en o pto g nu av M d b in d + ina om|f m x io Rig in ou els ri p|ini r. - ari r , es. ile|ng es d|Col16|l|Cr Te Te op Do XM de ib sp file wit cry Me Me|yp am am en ck Ri te rar eci s h pt xa xa|to T T K er g cti y l fic yst the om lz lz|m NT NT ub de cry on, oa di em p in th|in th er pl pt th di re , ro er rea|er re ne oy om is ng cto wh ce s.4 t|fa at tes m in th m ri ic ss 7 act|mi ac p en er re ec es h a es or 4|lie tor od ts s.4 at ha in re ru s a 8|s s t s to 6 T hij nis th as nn re|ar an de o ac m e / so ing lik|ge d pl ev ks to pr cia t el|t oy ad th hi oc te he y|e e de d|Col32|Col33|Col34|Col35| |---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---| ----- In Table 1, we show the cryptomining pools associated with the families analyzed in this report. Mining Pool Port Family Note 194.145.227[.]21 5443 Sysrv Proxy 80.211.206[.]105 6666 WatchDog Private pool monerohash[.]com Mexalz, TeamTNT, XMRig Public pool moneroocean[.]stream TeamTNT Public pool pool.hashvault[.]pro XMRig Public pool pool.minexmr[.]com 5555 Sysrv Public pool pool.supportxmr[.]com 443 Mexalz, TeamTNT Public pool xmr-eu1.nanopool[.]org 14444 Sysrv Public pool xmr-eu2.nanopool[.]org 14444 Sysrv, WatchDog Public pool xmr.f2pool[.]com 13531 Sysrv, WatchDog Public pool xmr.pool.gntl[.]co.uk 40009 WatchDog Public pool WatchDog WatchDog represents one of the longest running cryptomining operations.[51] The name of this threat, which is written in Go, is derived from the presence of a component that is tasked to monitor the execution of the actual cryptomining program, similar to the Linux utility “watchdog.” This operation has been running for more than two years, starting in January 2019, targeting both Windows and Linux hosts. Kinsing Threat actors behind the Kinsing cryptominer family are known to target vulnerable containerbased deployments.[52] More specifically, the attack exploits Docker API endpoints that are open to the world to download and install a number of shell scripts that aid in persistence and lateral movement, and ultimately lead to the download of a cryptomining component. |Col1|so|ci|ate|d|wi|th|th|e f|am|ili No Pro|es te xy|an|al|yz|ed|Col17|l|Cr O O wo vul an ve oth rel ho W W on op thr|yp me me rm ne d rsi er ati sts atc atc g er ea|to let let t ra Co on s on ” h hD est ati t,|m te te5 ha bil nfl s o yst sh SS Do o ru on wh|in 0 i t e itie ue f X em ip H g g r nn s.5 ic|er s a xp s nc M s s ( co ep in 1 T h i|fa cr loi in e t Ri by e.g nfi re g he s w|mi yp ts Ex o i g. e ., g f se cry n rit|lie to kn im ns It xpl th ile nt pt am te|s mi ow, W tal spr oit e “ ). s o om e n i|ni n e l m ea in kn ne in of n|ng bL o ds g t ow o in thi Go|og dif to ru n f t g s,|ic ied st _ he|Col33|Col34|Col35|Col36| |---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---| |.211.206[.]105 6666 WatchD onerohash[.]com Mexalz,|og Te|am|TN|T,|X|MR|ig|||Pri Pu|vat blic|e p p|oo ool|l|||||||||||||||||||||| |oneroocean[.]stream TeamTN|T|||||||||Pu|blic|p|ool||||||||||||||||||||||| |ol.hashvault[.]pro XMRig||||||||||Pu|blic|p|ool||||||||||||||||||||||| |ol.minexmr[.]com 5555 Sysrv||||||||||Pu|blic|p|ool||||||||||||||||||||||| |ol.supportxmr[.]com 443 Mexalz,|Te|am|TN|T||||||Pu|blic|p|ool||||||||||||||||||||||| |r-eu1.nanopool[.]org 14444 Sysrv||||||||||Pu|blic|p|ool||||||||||||||||||||||| **Table 1: Mining pools observed in the analyzed cryptominers.** ----- In Table 2, we show the wallets that the analyzed cryptominers used to collect the mined currency. Even though these wallets can be used to identify relationships between different campaigns, the anonymous and transient nature of these indicators is a real barrier to meaningful tracking and attribution. Monero Wallet Address Family Note 428uyvSqdpVZL7HHgpj2T5SpasCcoHZNTTzE3Lz2H5ZkiMzqayy19sYDcBGDCjobTfLBnc3t­ c9rG4Y8gXQ8fJiP5tqeBda 43Xbgtym2GZWBk87XiYbCpTKGPBTxYZZWi44SWrkqqvzPZV6Pfmjv3UHR6FD­ wvPgePJyv9N5PepeajfmKp1X71EW7jx4Tpz 43zqYTWj1JG1H1idZFQWwJZLTos3hbJ5iR3tJpEtwEi43UBbzPeaQxCRysdjYTt dc8aHao7csi­ Wa5BTP9PfNYzyfSbbrwoR 49dnvYkWkZNPrDj3KF8fR1BHLBfiVArU6Hu61N9gtrZWgbRptntwht5JUrXX1ZeofwPw­ C6fXNxPZfGjNEChXttwWE3WGURa 4BrL51JCc9NGQ71kWhnYoDRffsDZy7m1HUU7MRU4nUMXAHNFBEJhkTZV9H­ daL4gfuNBxLPc3BeMkLGaPbF5vWtANQn3gTBhyMDeJJJSvog 82etS8QzVhqdiL6LMbb85BdEC3KgJeRGT3X1F3DQBnJa2tzgBJ54bn4aNDju­ WDtpygBsRqcfGRK4gbbw3xUy3oJv7TwpUG4 85X7JcgPpwQdZXaK2TKJb8baQAXc3zBsnW7JuY7MLi9VYSamf4bFwa7SEAK­ 9Hgp2P53npV19w1zuaK5bft5m2NN71CmNLoh 87q6aU1M9xmQ5p3wh8Jzst5mcFfDzKEuuDjV6u7Q7UDnAXJR7FLeQH2UY­ FzhQatde2WHuZ9LbxRsf3PGA8gpnGXL3G7iWMv 88ZrgnVZ687Wg8ipWyapjCVRWL8yFMRaBDrxtiPSwAQrNz5ZJBRozBSJrCYffurn1Qg7Jn­ 7WpRQSAA3C8aidaeadAn4xi4k |Col1|ze el arr H|d c ati ier 5Zk|ry on to iM|pt shi m zq|om ps e ay|in b ani y19|er et ng sY|s u we fu Dc|se en l tr BG|d t di ac DC|o ffe ki jo|co re ng bTf|lle nt an LB|ct ca d nc|th m att 3t­|e m pa rib|in ign ut|ed s, io Fa Te|c th n. mi am|urr e ly TN|en an T|cy on|. ym|Ev o N|en us ote|an|d|Col29|Col30|Col31|Col32|Col33|Col34|Col35|Col36| |---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---| |Xbgtym2GZWBk87XiYbCpTKGPBTxYZZWi44S vPgePJyv9N5PepeajfmKp1X71EW7jx4Tpz zqYTWj1JG1H1idZFQWwJZLTos3hbJ5iR3tJpEtw a5BTP9PfNYzyfSbbrwoR|Wr Ei|kq 43|qvz UB|PZ bz|V6 Pe|Pf aQ|mj xC|v3U Ry|H sdj|R6 YT|FD t d|­ c8a|H|ao7|csi|­||Wa Wa|tc tc|hD hD|og og|||Ac|tiv|e|||||||||| |dnvYkWkZNPrDj3KF8fR1BHLBfiVArU6Hu61N9 fXNxPZfGjNEChXttwWE3WGURa|gtr|ZW|gb|Rp|tn|tw|ht5|JU|rX|X1Z|eo|fw|Pw|­||||Sys|rv||||||||||||||||| |rL51JCc9NGQ71kWhnYoDRffsDZy7m1HUU7MR|U4|nU|MX|A|HN|FB|EJ|hk|TZ|V9|H­|||||||Me|xal|z||||Ac|tiv|e|||||||||| Sysrv, WatchDog TeamTNT WatchDog TeamTNT Active **Table 2: Monero wallet addresses observed in the analyzed cryptominers.** ----- Interestingly, at the time of writing, the Monero wallet address 82etS8QzVh…3oJv7TwpUG4 was actively mining on xmr.nanopool[.]org, as shown in Figure 4. **Figure 4: Current cryptomining operation on xmr.nanopool.org.** Even more interesting, the first payment was made in October 2020, more than a year ago (see Figure 5). This shows how long-lasting and difficult it is to eradicate these mining operations. **Figure 5: History of payments to the cryptominer’s Monero wallet.** ###### Characterizing similarity We used both telfhash and our TF-IDF-based metric to characterize the similarity across the analyzed cryptominer families; the findings are shown in Figure 6. Because many of the cryptominers were packed, the analysis produced very poor results. For example, the similarity among samples of the Sysrv family was not captured. |ro igu|w re|alle 4|t .|ad|dr|ess|8|2e|tS|8Q|zV|h|…3|oJ|v7|Tw|p|UG|4|wa|s a|ct|ive|ly|Col26|Col27|Col28|Col29|Col30|Col31|Col32|Col33|Col34|Col35| |---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---| ----- **Figure 6: Code-based and string-based similarity between cryptominer samples (lighter color/lower distance corresponds to higher** similarity). Applying dynamic analysis makes it possible to unpack most of the samples, and Figure 7 shows the code and string similarity between samples after the unpacking process. The confusion matrix shows how some clusters of samples are clearly identifiable and how the samples evolve over time (see, for example, the various Sysrv family clusters). The results also show that, while telfhash is considered the state of the art for code similarity among ELF files, TF-IDF, which looks for similarity based on string hashes, provides a more useful characterizing metric. Applyistring omelette_0eaa4omelette_e2964omelette_71604watchdog_d5415watchdog_ed1e4watchdog_6f282kinsing_af3cckinsing_dd603kinsing_63643teamtnt_78f92teamtnt_a22c2teamtnt_d5870teamtnt_acbb4mexalz_dcc52mexalz_ed2aemexalz_b7a5emexalz_7c3a8mexalz_7edffsysrv_62ba6sysrv_18bc0sysrv_7e765sysrv_5f809sysrv_8bc38sysrv_40d2asysrv_afb6esysrv_17fbcsysrv_d5ce8sysrv_b8fe2sysrv_322ccsysrv_59737sysrv_72483sysrv_c42e5sysrv_6750esysrv_21f57sysrv_8f921sysrv_47183sysrv_3e66bsysrv_e627asysrv_2d5desysrv_d3196sysrv_ba469sysrv_6eaabsysrv_3bcbdsysrv_f487bsysrv_f640csysrv_77a9fsysrv_feb38sysrv_61e35sysrv_875f0sysrv_d93afsysrv_9df43sysrv_658bdsysrv_d5086sysrv_46276sysrv_a392asysrv_427ccsysrv_2d9c1sysrv_1ebfdsysrv_63162sysrv_35213sysrv_8c8eesysrv_f8472sysrv_d429asysrv_0cca2sysrv_f425fsysrv_dfeafsysrv_6ed86sysrv_0d3b0sysrv_1a7besysrv_ba518sysrv_896fdsysrv_0bca3xmrig_a34aexmrig_7579fxmrig_ee4a1xmrig_ef11cxmrig_b2e51xmrig_e7f40xmrig_6abddxmrig_1489cxmrig_42834xmrig_3d2e8xmrig_4484axmrig_cd37fxmrig_f72baxmrig_b1a5axmrig_65296xmrig_eb108xmrig_75253 similarity between samples after the unpang dynamic analysis makes it possible to unpack most ocking1.00.80.60.40.20.0 process.omelette_0eaa4omelette_e2964omelette_71604watchdog_d5415watchdog_ed1e4watchdog_6f282kinsing_af3cckinsing_dd603kinsing_63643teamtnt_78f92teamtnt_a22c2teamtnt_d5870teamtnt_acbb4mexalz_dcc52mexalz_ed2aemexalz_b7a5emexalz_7c3a8mexalz_7edffsysrv_62ba6sysrv_18bc0sysrv_7e765sysrv_5f809sysrv_8bc38sysrv_40d2asysrv_afb6esysrv_17fbcsysrv_d5ce8sysrv_b8fe2sysrv_322ccsysrv_59737sysrv_72483sysrv_c42e5sysrv_6750esysrv_21f57sysrv_8f921sysrv_47183sysrv_3e66bsysrv_e627asysrv_2d5desysrv_d3196sysrv_ba469sysrv_6eaabsysrv_3bcbdsysrv_f487bsysrv_f640csysrv_77a9fsysrv_feb38sysrv_61e35sysrv_875f0sysrv_d93afsysrv_9df43sysrv_658bdsysrv_d5086sysrv_46276sysrv_a392asysrv_427ccsysrv_2d9c1sysrv_1ebfdsysrv_63162sysrv_35213sysrv_8c8eesysrv_f8472sysrv_d429asysrv_0cca2sysrv_f425fsysrv_dfeafsysrv_6ed86sysrv_0d3b0sysrv_1a7besysrv_ba518sysrv_896fdsysrv_0bca3xmrig_a34aexmrig_7579fxmrig_ee4a1xmrig_ef11cxmrig_b2e51xmrig_e7f40xmrig_6abddxmrig_1489cxmrig_42834xmrig_3d2e8xmrig_4484axmrig_cd37fxmrig_f72baxmrig_b1a5axmrig_65296xmrig_eb108xmrig_75253 f the samples, and Figure 7 shows the code and 1.00.80.60.40.20.0 **Figure 7: Code-based and string-based similarity between cryptominer samples after unpacking (lighter color/lower distance** corresponds to higher similarity). |Col1|1.0 0.8 0.6 0.4 0.2 0.0|oookkk mmmmmmmmiii eee wwwttttaaaeeeettt|xxxxxxxxxxxxxxxxxeeeeennn mmmmmmmmmmmmmmmmmxxxxxsss rrrrrrrrrrrrrrrrraaaaaiii iiiiiiiiiiiiiiiiilllllnnn gggggggggggggggggzzzzzggg _________________________ a7eebe61434cfb6e7deb77ad6 aaaalll mmmmeee ttttttt nnnnttt tttteee _______ 7ada0e7 ssssssssssssssssssssssssssssssssssssssssssssssssssssss cccyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy hhhssssssssssssssssssssssssssssssssssssssssssssssssssssss dddrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr ooovvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv ggg______________________________________________________ ___16789d1bd0b97567a1beddb98f152482175c98479d90081c3521a5 de6|35ef27a42d4d715b5cd7cefd3 4741efb882832a212c2a3d366 a9a154d93e47b59055a5afc04 ef1c10dc48afaa6832ee8fc33 82dce21 f28ba96 9c0ba60 2234444 a723dd3cdcec2f7a9df643ab24822f49cf4559d97e44b1b7aff6ff 5df6f05858b31a945559d22214228a0ed869f45fb681c5c6e2e61a37c 41230335b4013ab8d0492c709603788f3ed15d79ced06c10591bd5ec4 1e8f348b472bb0735e6dc4a96921b7c97d3ef20f85162df3b03718f5c 542 oookkk mmmmmmmmiii eee ssssssssssssssssssssssssssssssssssseeeeennn lll yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyxxxxxsss eee sssssssssssssssssssssssssssssssssssaaaaaiii ttt rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrlllllnnn ttt vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvzzzzzggg eee ___________________________________________ ___ 571284251f89bddeb1a76579b0db1d9876177bed6da 7e0 4fc94f22842ba346fd9a7f2cecdc3dd327aec7dc3df 12e 4f968de0a82241222d955549a13b85850f6d3a2c663 69a d51de3f887306907c2940d8ba3104b53303fa5a540c 06a 2fe3d79c7b12969a4cd6e5370bb274b843ff8ee233c 444|aaaa mmmm tttt nnnn tttt ____ ada7 cd28 b82f b0c9 4322 wwwtttt aaaeeee ttt ccc hhh ddd ooo ggg ___ 6ed fd5 214 8e1 245 xxxxxxxxxxxxxxxxxsssssssssssssssssss mmmmmmmmmmmmmmmmmyyyyyyyyyyyyyyyyyyy rrrrrrrrrrrrrrrrrsssssssssssssssssss iiiiiiiiiiiiiiiiirrrrrrrrrrrrrrrrrrr gggggggggggggggggvvvvvvvvvvvvvvvvvvv ____________________________________ 7e6bfc43416ebee7a5a1253c18009d97489c 5b517d4d24a72fe53ff6ffa7b1b44e79d955 212a238288bfe1474c73a16e2e6c5c186bf5 5095b74e39d451a9a4ce5db19501c60dec97 386aafa84cd01c1fec5f81730b3fd26158f0|Col7|1.0 0.8 0.6 0.4 0.2 0.0|Col9|Col10|Col11|Col12|Col13|Col14|Col15|Col16| |---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---| ||||||||||||||||| e and ----- When we ordered the samples by similarity, not by time, the clusters became even more evident, as shown in Figure 8. In particular, the similarity between some TeamTNT samples, Mexalz and XMRig, as well as the similarities between WatchDog and XMRig, are clearly emphasized. In addition to unpacking the cryptominer samples, [we also monitored their execution in our sandbox.](https://blogs.vmware.com/networkvirtualization/2021/12/introducing-darth-distributed-analysis-for-research-and-threat-hunting.html/) We found that a subset of the samples was de-obfuscating and executing additional code at runtime. We extracted these code fragments and analyzed their similarity against the model we built for the existing cryptominers. Note that the similarity is based only on the strings. The dynamically generated code is not in ELF format, therefore telfhash cannot be applied. This further shows that TF-IDF analysis on strings is an effective and flexible approach with wider applicability than telfhash. The results of the analysis are shown in Figure 9. It shows that the generated code has a few clusters that represent small variations of the deployed code. |not, a d tc|b s hD|y og|Col4|Col5|Col6|Col7|1.0 0.8 0.6 0.4 0.2 0.0|Col9|Col10|kkkmmmmmtwxxxxxxtxxssssssssssssssssssssssssssiiieeeeeeammmmmmemmyyyyyyyyyyyyyyyyyyyyyyyyyynnnxxxxxatrrrrrrarrssssssssssssssssssssssssss|sssaaaaamciiiiiimiirrrrrrrrrrrrrrrrrrrrrrrrrriiilllllthggggggtggvvvvvvvvvvvvvvvvvvvvvvvvvvnnnzzzzznd______n____________________________ggg_____toee61e4tbc5c62842d963e3f7f686d4a601b___deb77_gefa474_1d9471f7d3dee6b67e175963edaaad6cd7ec7_41b8f8da3725f9151fa62c4abe58329d375fd3c2ad386a1d9445573e0528d94a67b0933fba728bb13665a5faff1cdc0a8af75e713e63bbadcf850df6a60e8|c042eef892c33 282 70|Col14|Col15|Col16|Col17| |---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---| |||||||||||||||||| |||||||||||||||||| **Figure 8: Cryptominers ordered based on string similarity (instead of** family and time), showing the dendrograms that cluster together similar samples (lighter color/lower distance corresponds to higher similarity). 1.0 0.8 0.6 0.4 0.2 0.0 omelette_43c22 sysrv_e4e76 teamtnt_d9e3b sysrv_97f95 sysrv_255f8 sysrv_980b8 sysrv_56c64 sysrv_b5ecc sysrv_d5407 sysrv_9ec38 sysrv_09783 sysrv_6ee80 sysrv_3141e sysrv_373c3 sysrv_776d0 sysrv_7b70e sysrv_e951b sysrv_0498d sysrv_e64f8 sysrv_d0e1b sysrv_d13d3 sysrv_96e62 sysrv_e5732 sysrv_a1bc5 sysrv_fa72f sysrv_fe059 sysrv_88d1d sysrv_f6f89 sysrv_8d6d1 sysrv_a5bb7 sysrv_8627a sysrv_76d61 sysrv_e9d5a sysrv_32aa0 sysrv_e19b2 sysrv_fde31 sysrv_8d1b0 sysrv_07ef1 sysrv_08f6a sysrv_d27c1 sysrv_3f199 sysrv_e106e sysrv_64225 teamtnt_03d7e **Figure 9: Similarity analysis of dynamically generated code.** kinsing_af3cckinsing_dd603kinsing_63643mexalz_dcc52mexalz_ed2aemexalz_b7a5emexalz_7edffmexalz_7c3a8teamtnt_78f92watchdog_6f282xmrig_ee4a1xmrig_ef11cxmrig_6abddxmrig_1489cxmrig_e7f40xmrig_4484ateamtnt_d5870xmrig_b1a5axmrig_cd37fsysrv_59737sysrv_c42e5sysrv_6750esysrv_21f57sysrv_8f921sysrv_47183sysrv_2d5desysrv_d3196sysrv_9df43sysrv_6eaabsysrv_3e66bsysrv_e627asysrv_3bcbdsysrv_f640csysrv_77a9fsysrv_feb38sysrv_61e35sysrv_875f0sysrv_658bdsysrv_d93afsysrv_46276sysrv_a392asysrv_6ed86sysrv_0d3b0sysrv_1a7besysrv_ba518sysrv_896fdsysrv_0bca3sysrv_427ccsysrv_2d9c1sysrv_1ebfdsysrv_63162sysrv_f8472sysrv_35213sysrv_8c8eesysrv_d429asysrv_0cca2sysrv_f425fsysrv_dfeafsysrv_d5086sysrv_62ba6sysrv_7e765sysrv_5f809sysrv_40d2asysrv_8bc38sysrv_afb6esysrv_17fbcsysrv_d5ce8sysrv_b8fe2sysrv_322ccsysrv_18bc0teamtnt_a22c2teamtnt_acbb4watchdog_d5415watchdog_ed1e4xmrig_a34aexmrig_65296xmrig_7579fxmrig_b2e51xmrig_42834xmrig_3d2e8xmrig_f72baxmrig_eb108xmrig_75253omelette_0eaa4omelette_e2964omelette_71604sysrv_72483sysrv_ba469sysrv_f487b ----- ###### Characterizing behavior We also used CAPA to examine the behaviors of cryptomining samples. The malicious behaviors of the cryptomining samples are shown in Figure 10. Similar to the behaviors observed in the ransomware samples, defense evasion is the most commonly used technique by cryptominers. In terms of the encryption methods associated with defense evasion, it appears the techniques cryptominers use to obfuscate data are more diversified (Figure 10 (B)) in comparison to the ransomware samples discussed earlier (Figure 3 (B)). Defense Evasion::Obfuscated Files or Information T1027.005, 57.6% (200) Discovery::System Information Discovery - T1082, 15.0% (52) Discovery::System Network Configuration Discovery - T1016, 6.9% (24) (A) Execution::Shared Modules - T1129, 6.3% (22) Defense Evasion::Deobfuscate/Decode Files or Information - T1140, 5.5% (19) Impact::Resource Hijacking - T1496, 5.5% (19) Discovery::File and Directory Discovery - T1083, 3.2% (11) |s o . S te he e r|f c im ch te an|ry ila niq ch so De T10 Dis 15. Dis Dis Ex De Inf|pt r t u niq m fen 27 co 0% co co ecu fen orm|om o t e b ue wa se .00 ver (5 ver ver tio se ati|ini he y s re Eva 5, y::S 2) y::S y - n::S Eva on|ng b cry cry sa sio 57. yst yst T10 ha sio - T|s eh pt pt m n:: 6% em em 16, red n:: 114|am av o o ple Ob (20 In N 6. M De 0, 5|pl ior min min s fus 0) for etw 9% odu obf .5|es s er er dis cat mat ork (24 les usc % (1|. T ob s. s cu ed ion Co ) - T ate 9)|he ser In use ss File Di nfi 112 /D|m ve te t ed s o sco gur 9, eco|ali d rm o o e r In ver ati 6.3 de|ci in s bf arli for y - on % ( Fil|ou th of us er ma T1 22) es|s b e r th ca (F tio 082 or|eh an e e te ig n -,|av so nc da ur|io m ry ta e 3|rs wa pti ar (B|of re on e )).|th sa m mo|e m et re|ple ho|s, ds|Col28|Col29|Col30|Col31|Col32|Col33|Col34|Col35| |---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---| (B) aes, 18.5% (37) base64, 18.5% (37) rc4 prga, 10.0% (20) xor, 10.0% (20) rc4 ksa, 9.5% (19) curve25519, 8.5% (17) salsa20 or chacha, 6.5% (13) blowfish, 6.0% (12) camelia, 6.0% (12) stackstrings, 6.0% (12) upx, 0.5% (1) **Figure 10: Malicious behaviors of the cryptominer samples in the dataset: (A) Typical MITRE ATT&CK tactics and techniques** leveraged by the samples; (B) Various encryption/obfuscation techniques used for defense evasion. ###### Detecting and mitigating the threat A cryptojacking attack might result in higher energy bills, stalled operations, or higher cloud computing costs. Unfortunately, these attacks can be tricky to detect because they do not completely disrupt the operations of cloud environments, like ransomware does, or raise alarms, like a data breach might when unauthorized or anomalous access to sensitive data is detected. The best way to detect cryptojacking attacks is to use network traffic analytics (NTA) to identify internal hosts that are communicating the results of mining work to the outside, as this communication is required to monetize the attack. The communications to look for are connections to mining pools. However, many cryptomining ----- malware samples connect to a command-and-control host that acts as a network proxy to avoid being detected. In these cases, more sophisticated anomaly detection techniques are necessary to identify the threat. EDR solutions may be able to identify abnormal CPU usage patterns that can be directly associated with the calculations related to blockchain mining. Once again, the concerted monitoring of cloud environments using both host-based and network-based detection techniques can help keep these attacks at bay. ###### Methodology Static and dynamic analysis Linux programs, malicious or not, can be analyzed with a number of different techniques that can be categorized into two classes: static and dynamic analysis. Static analysis looks at Linux binaries without executing them. These techniques either extract the metainformation provided by the ELF binary format or investigate the code and data segments that are part of the binary (e.g., looking for strings used by the program). For example, pyelftools[21] is a Python library that can extract information from ELF files. Another example is the FLIRT technology provided by the IDA Pro disassembler[22] that enables the identification of specific libraries in statically linked, stripped binaries, where all the symbols associated with the source code have been removed. Another interesting tool is redress,[23] which can be used to analyze Linux programs written in the Go language. The advantage of static analysis techniques is that they are typically fast and don’t require the execution of the program’s code, which might include malicious actions. For example, the CAPA tool[24] can extract interesting behaviors without having to execute a sample. However, the main disadvantage of static analysis is that it is relatively easy to foil, using layers of obfuscation, packing and encryption. For example, the most used codesimilarity function for ELF files, telfhash,[25] is of limited effectiveness when the files are packed. Dynamic analysis looks at the actual execution of a program, usually in a controlled environment, such as a sandbox. These techniques are often resource-intensive and require extreme care to avoid the “spill out” of malicious actions or the fingerprinting of the analysis environment. However, the main advantage of dynamic analysis techniques is that they have the potential to expose the hidden behavior of malicious programs (e.g., encrypted portions of code). The Linux kernel has recently introduced a technology, called eBPF,[26] that allows for the monitoring of [programs with minimal overhead. Tools built on top of eBPF, such as Tracee,[27] can identify specific malicious](https://github.com/aquasecurity/tracee) behaviors, such as the unpacking of code or the presence of suspicious sequences of system calls. In this report, we have applied a composition of static and dynamic techniques to characterize various families of malware observed on Linux-based systems. ###### Malware datasets As part of this report, we are releasing a curated dataset of metadata associated with Linux binaries. All the [samples in this dataset are public and therefore they can be easily accessed using VirusTotal[28] or various](https://www.virustotal.com/) websites of major Linux distributions. |-c ete U e n t lyz mic ex at ro|on ct us ag ec ed a ec or gra|tro ion ag ain hn w na uti inv m|l h t e , t iq ith lys ng es ).|os ec pat he ue a is. th tig Fo|t t hni te co s c nu e at r e|ha qu rn n an m m. e t xa|t a es s t cer h be Th he m|cts ar hat te elp r o es c ple|a e c d k f e od , p|s a ne an mo ee diff tec e a ye|n ce be ni p t er h n lft|etw ss d tor he en niq d d oo|o ary ire in se t t ue at ls2|rk to ctl g o at ec s a s 1 is|pr id y a f c tac hn eit eg a|ox e ss lo ks iq he m P|y t ntif oc ud a ue r e en yth|o a y t iat e t b s t xtr ts on|vo he ed nvi ay hat ac th li|id th w ro . c t t at br|b re ith nm an he ar ary|ein at t e be m e p th|g . E he nts et ar at|de DR us a- t o ca|tec in f t n|te g he|d.|Col29|Col30|Col31|Col32|Col33|Col34|Col35| |---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---| ----- We started by collecting more than 11,000 benign samples from several Linux distributions, namely Ubuntu, Debian, Mint, Fedora, CentOS and Kali. We then collected a dataset of samples for two classes of threats, namely ransomware and cryptominers. These datasets have been manually labeled and vetted. This is a resource-intensive process that provides better labels than the ones provided by most automated analysis tools, which can be noisy and imprecise. Finally, we collected a dataset of malicious ELF binaries from VirusTotal that we used as a test malicious dataset. We started collecting the dataset in June 2021 and concluded in November 2021. For each sample in each dataset, we looked at the general characteristics of the program, such as the architecture, the type of linking (static or dynamic), the presence or absence of symbols, the use of UPX for packing, and other traits. Figure 11 displays the characteristics of the files in our datasets, which show how different the characteristics of each group are. **Figure 11: Characteristics of the samples in the datasets.** |enign hen c e dat ter la lly, w ataset at the amic) he ch e.|sa ol ase be e . g , t ara|m lec ts ls co We en he ct|ple te ha tha lle st er pr eri|s d v n ct ar al e st|fro a d e b th ed te ch se ics|m se atase een m e one a dat d colle aracte nce or of th|veral L t of sa anual s provi aset of cting ristics absen e files i|inu mp ly l de m the of ce n o|x distrib les for t abeled a d by mo alicious dataset the prog of symb ur datas|utions, n wo class nd vett st autom ELF bina in June ram, su ols, the ets, whi|a es ed a ri 2 ch us ch|me of . T te es 02 a e s|ly Ub threa his is a d analy from 1 and s the of UPX how h|untu, ts, sis for ow|Col16|Col17|Col18|Col19|Col20|Col21|Col22|Col23| |---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---| ----- #### Remote access tools – Implants An important aspect of an adversary’s activity is how they compromise systems to gain control. This control allows them to persist within the environment, establishing a staging server they can use to pivot and target additional systems. Once an adversary has gained initial access to an environment, they enter the most difficult portion of the attack. They will need to find a way to leverage this limited access to gain a stronger foothold, while attempting to map out and find resources to accomplish their goal. Attackers look to install an implant on a compromised system that gives them partial control of the machine. An implant, also known as a beacon, is what is generally regarded as the malware component of an attack. Its goal is to simply make regular network connections out to the command-and-control (C2) server to obtain new commands to execute and pass along the results. In the context of an attack, what is an implant? Malware, webshells, remote access Trojans, and even knowngood RATs can all be implants that install themselves on a compromised system to allow for remote access. An implant is deployed in a persistent manner to allow an adversary to keep control of that infected system. This is typically done in two ways: passive and active. A passive implant awaits an external connection, such as a webshell on a compromised server. Conversely, an active implant will continually try to send beacon messages to a preset C2 server and await further instructions. Analysis of RATs in the wild shows that most act as active implants that will communicate with known C2 servers to gather further instructions. Very few RATs make use of passive implants that rely on a service to listen for commands. While such malware could create its own listener, often they install a component into an existing service, such as a web server, to piggyback on existing network connectivity. However, the adversary would need to perform additional research of the infected system and face the risk of insufficient account privileges to install. Because a passive implant has no guarantee that the system will allow incoming connections, an active implant is the preferred tactic for malware. From a malware analysis perspective, what is interesting is determining the number of implants that interact via well-known HTTP protocols, and those that create their own specialized protocols. An implant’s purpose is farreaching, depending on its author. Many are used for very simplistic purposes, such as to show files on the system, download new files, upload existing files, or execute commands. Others allow for more advanced tactics, such as mapping out the local network and pivoting from the infected system into new systems on the network. Overall, depending on the adversary and their ability, an implant can contain a great amount of functionality, as documented in Figure 12. |Col1|Col2|Col3|Col4|Col5|Col6|Col7|Col8|Col9|Col10|Col11|Col12|Col13|Col14|Col15|Col16|Col17|Col18|Col19|Col20|Col21|Col22|Col23|Col24|Col25|Col26|Col27|Col28|Col29|Col30|Col31|Col32|Col33| |---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---| |||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||| ||||||||||||||e rs s. c o n n||o t m ta w|||a i a u i a||||||||||||||| ----- Communicate with C2 server using HTTP, HTTPS or other custom protocol **Main** **Exfiltration** **Reconnaissance** Encrypts send and receive data/file **Lateral** **Movement** Deploy additional malicious payload to all system/network Server Computer Computer **Figure 12: Malicious implant diagram.** ###### Tactics used by implants |HT|Con Com TP, in C|nec mun HTT Mali vic red|t wi icate PS or Main ciou tim’ ent|th wi o s i s m ia|C2 th C ther mpl ac l T|ser 2 se cus ant hin heft|ver rve tom e|r pro|toc|ol|Col12|Col13|Rec En|on tre|nai nch|ssa me|nce nt|leg|C s Ins itim loa|olle yste tall/ ate d its|ct a m in|nd g for|ath mati itse /ser me|er on lf as vice mory|s or|Col27|Col28|Col29|Col30|Col31|Col32|Col33|Col34|Col35| |---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---| ||||||||||||||||||||||exec proc elf i|ute ess nto||||||||||||| Steal victim’s credential Elevate privileges Keylogging Implants often perform reconnaissance on systems in the area. For instance, they may scan an entire set of IP addresses to collect systems information and grab TCP port banner data. This can also allow the implant to collect IP addresses, hostnames, active user accounts, and specific operating systems and software versions of all the systems it detects. Implants also rely on their ability to entrench themselves within their infected systems to persist. Their hope is to become background noise within a typical day’s activity, showing up as just another Windows service or application to operate undetected. They can hide themselves in various ways, but on Linux-based multi-cloud environments, we often see their activities performed as routine cron jobs. Like the Scheduled Tasks within Windows, cron allows Linux, macOS and Unix environments to schedule processes to be executed at regular intervals. In this way, malware can implant itself onto a compromised system with a restart frequency of 15 minutes, so it can relaunch if it is ever terminated. ----- One of the more advanced tactics used by implants is that of lateral movement. Also known as pivoting, this allows an adversary to install additional implants within the environment, allowing them to jump to another system internally. From here, they can start gathering additional data about the environment from systems that may have additional access. In incident responses seen in the past, there are specific systems that have higher privileges to connect into protected enclaves for more sensitive data. These protected enclaves do not have remote access but could be accessed via multiple pivots, allowing a patient and careful adversary the ability to test access and find the weak center of the infrastructure. Implants could be active for weeks, or even months, as the adversary figures out how best to carry out their objectives. In a typical smash-and-grab ransomware scenario, the actor may get lucky—they could sit dormant on a Windows server they’ve compromised and scan logons for just a few days before they catch a domain administrator. Once they’ve got these stolen credentials, they can quickly pivot and use them to force ransomware across an entire environment using built-in PowerShell scripting capabilities. However, this task is more difficult in a multi-cloud environment. The actor typically must remain quiet and unnoticed for as long as possible while they discover all the required resources. Implants are also invaluable for collecting and exfiltrating data. Unlike largescale data collection, which is typically done through tools such as rclone, implants may have the ability to exfiltrate directory listings of existing files and individual files. This allows a malware operator to collect superficial data for a malicious analyst to identify critical assets to steal. ###### Attack stages These implants allow for additional stages of attack. While a first stage may be to exploit a vulnerability and install an implant, a second stage may be to download additional malware. This is often seen in Windows attacks via malware, such as TrickBot and QBot. The same exists in multi-cloud environments, as adversaries tend to specialize their toolsets based on functionality. The initial implant may have very specific capabilities, but it can be leveraged to download and execute ransomware or a cryptomining application, such as those mentioned earlier in this report. Within the data center, adversaries may have to juggle access and connections to a variety of operating systems and services. In some cases, it could be necessary to pivot between systems instead of making direct connections, especially if some services are virtually segmented and only allow connections from a hard-coded set of systems. Lucky for them, it is completely possible to |pla ary p t l d nci ivi ct ots e o ic si t a e s are|nt t o at de leg ed, a we nth al t d fe tol a|s i o i an a a nt es en llo ak s, sm or w en cr|s t nst ot b re t cl w c as as m da cr oss|ha all he out sp o c av ing en th h- an ys ed a|t o a r s th on on es a ter e an t o b e n e|f l ddi yst e se ne do p of ad d- n a efo nti nt|ate tio e en s s ct n ati th ve gr W re als ire|ra na m i vir ee in ot en e rsa ab in th, t e|l m l i nte on n to ha t a inf ry ra d ey he nv|o mp rn m in pr ve nd ra fi ns ow c y c iro|ve la all en th ot re c str gu om s s atc an n|me nt y. t f e p ect m are uc re w er h me|nt s ro as ed ot fu tur s o ar ve a nt|. m t, e l e. ut e r|Col16|Col17|Im Co Ve Co we re as bu an fro Ve thr on ma Str|pl ba rm ba ll- d t a l sin d m rm ea C ki ik|an lt ili lt kn ea eg es DN a ili t e ob ng e s|ts St on Str ow m iti se S co on m alt it er|us rik S ik n to ma s. to mp St ula St co ver|e e a tri e is an ols te It ex ro rik tio rik m s.|d n ke o d o se us fil m e i n e’ pa|by d ne we n t rv es inf ise s a so s p tib|th of ll- he ice HT or d n ftw ro le|re th re m to T ma ne op ar to wi|at e gar ar s P, tio tw en e col th|ac m de ket ele HT n or s ba s, Co|to ost d, s ct TP k. ou se ba|rs ol S rc d lt|d e|Col33|Col34|Col35| |---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---| Merlin [Merlin[74 ]is a post-exploit C2 tool](https://github.com/Ne0nd0g/merlin) that communicates using the HTTP/1.1, HTTP/2 and HTTP/3 protocols. The server and implant are written in Go, so they can be cross-compiled to run on any OS platform. ----- traverse an environment using simple command lines and built-in accessibility tools, such as SSH. However, mapping out an environment, as well as the resources found on each system, is difficult for someone using direct connection techniques. This creates the need for an attack management tool. ###### Attack management tools Attack management tools are good for both attackers and red team operations. They provide the ability to graphically organize assets, store collections of notes, and easily transmit properly structured commands to multiple compromised systems. At a basic level, they allow the actor to map out accessible IP addresses and hostnames within an environment and identify their operating systems. The actor can then target specific systems for exploitation, track legitimate user accounts and credentials, and document which systems have what assets. ###### A deeper look at Cobalt Strike – Vermilion Strike The primary implant that this report focuses on is Cobalt Strike and its recent Linux-based variant, Vermilion Strike. To fully understand its impact on a multicloud environment, this report will dive into the implant’s capabilities and methods of operation. Cobalt Strike is a commercial penetration testing and red team tool. It allows a red team to simulate real attacks during their testing. Unfortunately, threat actors have found the tool useful, as well, thanks to its robust feature set, which makes it easy to remotely control victim machines once they are infected. Cobalt Strike uses an implant named beacon that, once deployed on a machine, will phone home to retrieve tasks to execute. Many threat actors simply use the Cobalt Strike beacon for their final payload delivery. The beacon implant is a Windows-only application. [In September 2021, Intezer reported[53] that they had discovered malware that](https://www.intezer.com/blog/malware-analysis/vermilionstrike-reimplementation-cobaltstrike/) appeared to be a Linux re-implementation of the Cobalt Strike beacon implant. [Open source versions of Cobalt Strike’s beacon implant exist, such as Geacon[54]](https://github.com/darkr4y/geacon) [and CrossC2,[55] but Vermilion Strike appears to be the first re-implementation of](https://github.com/gloxec/CrossC2) the Cobalt Strike protocol in the wild. Because Cobalt Strike is such a ubiquitous threat on Windows, its expansion to other operating systems, such as Linux, is notable. It demonstrates the desire of threat actors to use readily available remote-control tools to target as many platforms as possible. Vermilion Strike appears to be implemented against version 3 of the Cobalt Strike team server. Its C2 configuration and communication appear to be the same as Cobalt Strike, but it only supports a handful of commands. These commands are explained in more detail in the technical analysis in Figure 13. SSH backdoor implant [An SSH backdoor implant[75] can](https://blogs.juniper.net/en-us/threat-research/linux-servers-hijacked-to-implant-ssh-backdoor) be loaded when a malicious actor exploits a control web panel (CWP) server administration web application and downloads a sshins installer binary. This drops a malicious shared library, /lib64/libs.so, and writes the name of the dropped file in the directory as /etc/ld.so.preload. When the OpenSSH service restarts, the malicious library will load and have the ability to inject its own code whenever sshd calls bind(). It then uses this hook to periodically beacon to the C2 server and exfiltrate sensitive data, such as CPU and OS information, OpenSSH configuration, and other critical data. Linux C2 malware – RedXOR [RedXOR[76] masquerades as](https://securityboulevard.com/2021/04/detect-c2-redxor-with-state-based-functionality/) a polkit daemon. It is named for its network data encoding scheme, which is based on XOR. It communicates with a C2 server over a TCP socket and makes the traffic look like HTTP traffic. The C2 server sends commands to the implant via a command code that is returned in a JSESSIONID cookie. These commands can include collect system information, upload file, open file, execute shell command, and other tasks. |nd e r s k att e an to en loi ch|li nv o ma ac as ds m tify tat sy Ve|ne iro me na ker set to ap t io ste r|s a n on ge s s, m o hei n, m m|nd me e m an st ul ut r o tra s h ili|b nt, usi en d r ore tip ac p ck av o|uil a ng t t ed c le ce era le e n|t-i s w d oo te oll co ssi tin git wh St|n a el ire l. a ec m bl g im at ri|cc l a ct m tio pr e I sy at as ke|es s t co op ns om P a ste e u se|si he nn era of is d m se ts.|bili ec ti n ed dre s. r|ty tio on ote ss Th|n s. s, es e|Col16|l|Im SS An be ex (C ap ssh ma /lib na dir W res oa|pl H S|an ba SH|ts ck b|us do ac|e or kd|d im oo|by p r i|th lan mp|re t la|at nt7|ac 5 c s a el n a dr e t oa e ry in|to an ct we op he d. wi je|rs or b s ll ct|a|Col33|Col34|Col35| |---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---| |||||||||||||||||||lo plo W pli in lic 6 me ec he ta d|ad its P) ca s i io 4/li o tor n t rts an|ed a ser tio nst us bs f t y he , t d|w co ve n a all sh .s he as O he ha|he nt r a nd er ar o, dr /e pe m ve|n rol d d bi ed an op tc/ nS ali th|a m w mi ow na lib d w pe ld. SH cio e a|al eb nis nl ry. ra ri d so s us bil|ici p tra oa T ry, tes file .p er lib ity|ou an tio ds his th in rel vic ra to|||||||| ----- ``` File Name : 294b8db1f2702b60fb2e42fdc50c2cee­ 6a5046112da9a5703a548a4fa50477bc File Size : 89,416 bytes MD5 : 3db3e55b16a7b1b1afb970d5e77c5d98 SHA256 : 294b8db1f2702b60fb2e42fdc50c2cee­ 6a5046112da9a5703a548a4fa50477bc Fuzzy : 1536:tMCIVGxHiGZsz9ZLTSKKTrcAFgtzgrSWUnCTOPS:tMCIVUbi z9VT1KTwAFgtzgrFO Magic : ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[s ha1]=2322a87e5a86ac36f71d745a4b290772f4b3614e, stripped ``` **Figure 13: Analysis of Vermilion Strike file on Linux.** ###### Vermilion Strike configuration details The malware has multiple encoded blocks of data that it loads at start-up. The first is a 4,096-byte block of data that is XOR-encoded with the key 0x69. After decoding this first block, we can see that it is a group of type-length-value (TLV) encoded values consistent with a Cobalt Strike beacon. The use of the 0x69 decryption key implies that this beacon might be similar to Cobalt Strike 3.x beacons. Cobalt Strike 4.x beacons make use of the 0x2e key to decrypt. Next, the malware decodes five separate blocks of string data. These chunks of data have 12 bytes of a header and a variable length chunk of XOR-encoded data. As shown in Figures 14 and 15, the first 4 bytes always appear to be “80 ``` 80 00 00”. The second 4 bytes make up a 4-byte key to be used with XORing ``` the encrypted data. The third 4 bytes indicate the length of the data. In the example shown in Figure 14 and 15, we can see a key of “e2 16 a2 de” used to decode 181 (0xb5) bytes of data. BlackTech – ELF_Plead ELF_Plead[78] is a Linux version of a RAT used by the threat actor BlackTech. The configuration is RC4-encrypted, and a 32-byte encryption key can be found before the encrypted configuration. It uses a custom protocol to communicate with a C2 server. The data sent to the C2 server is RC4-encrypted and then LZO-compressed. The ELF_Plead command can provide arbitrary shell command execution and send/receive files, among other things. |c50 a50 e77 c50 a50 KTr e, rpr r G d74|c2 47 c5 c2 47 cA x8 et NU 5a|ce 7b d9 ce 7b Fg 6- er /L 4b|e­ c 8 e­ c tz 64 / in 29|gr , li ux 07|SW ve b6 2 72|Un rs 4/ .6 f4|CT io .3 b3|OP n 2, 61|S: 1 B 4e|tM (S ui ,|CIV YSV ldI|Ub ), D[|i s|Col15|Col16|Col17|Im AC AC|pl B B|an ac ack|ts kd d|us oo oo|e r r77 cu ar er u m es T io od E 8 is|d ma pr tio bit sis pd ise w PS n it ed LF a|by lw ov n rar te at d ith pr c p _ Li|th ar id of y nc e m sy a ot oll ay Ple nu|re e es sh bin e, al ste C2 oc ect loa ad x v|at ell ar an w m s ol s a d. er|ac y d are . It erv to s sio|to er se a n|rs nd of|Col32|Col33|Col34|Col35| |---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---| ||||||||||||||||||arb co ex the on co usi the Ba Bla EL|itr m ec a a m ng in se ck F_|ar ma uti bil co mu th fo 64 T Pl|y e nd on ity m ni e rm -e ec ea|xe s, , p to pro cat HT at nc h – d7|||||||||||||| ----- ``` 00000000 80 80 00 00 e2 16 a2 de b5 00 00 00 cd 75 c3 fe |....â.¢Þµ...ÍuÃþ| 00000010 cd 49 fd ab 96 7b 8c b9 8b 70 82 f1 92 7f da bb |ÍIý«.{.¹.p.ñ..Ú»| 00000020 8e 38 c5 b7 84 36 8d b9 cc 66 cb a6 87 7a 82 f1 |.8Å·.6.¹Ìf˦.z.ñ| 00000030 86 79 d6 f0 85 7f c4 fe cd 63 d2 ba 83 62 c7 ad |.yÖð..ÄþÍcÒº.bÇ.| 00000040 cc 64 d1 ad c2 39 c4 a9 8e 7f cc b5 c2 39 c1 b3 |ÌdÑ.Â9Ä©..̵Â9Á³| 00000050 c2 39 c1 a6 c2 39 d2 b7 9a 73 ce fe cd 7b c3 aa |Â9Á¦Â9Ò·.sÎþÍ{ê| 00000060 81 7e 82 f1 94 7f d1 b7 96 38 c8 ad c2 39 ce b1 |.~.ñ..Ñ·.8È.Â9α| 00000070 83 72 82 f1 92 63 d1 b6 c2 39 d2 aa 88 36 8d b4 |.r.ñ.cѶÂ9Òª.6.´| 00000080 cc 77 c6 fe cd 71 c3 f0 88 65 82 f1 87 78 fd 8b |ÌwÆþÍqÃð.e.ñ.xý.| 00000090 b1 39 c3 b2 8e 38 c8 ad c2 39 c3 bd 96 7f d4 b7 |±9ò.8È.Â9ý..Ô·| 000000a0 96 6f 82 f1 ab 53 9b 9d 8d 7b d2 bf 96 40 cb bb |.o.ñ«S...{Ò¿.@Ë»| 000000b0 95 5a cb ad 96 |.ZË..| ``` **Figure 14: Vermilion Strike encrypted string data.** ``` 00000000 2f 63 61 20 2f 64 70 69 78 65 6c 20 2f 5f 5f 75 |/ca /dpixel /__u| 00000010 74 6d 2e 67 69 66 20 2f 70 69 78 65 6c 2e 67 69 |tm.gif /pixel.gi| 00000020 66 20 2f 67 2e 70 69 78 65 6c 20 2f 64 6f 74 2e |f /g.pixel /dot.| 00000030 67 69 66 20 2f 75 70 64 61 74 65 73 2e 72 73 73 |gif /updates.rss| 00000040 20 2f 66 77 6c 69 6e 6b 20 2f 63 6d 20 2f 63 78 | /fwlink /cm /cx| 00000050 20 2f 70 69 78 65 6c 20 2f 6d 61 74 63 68 20 2f | /pixel /match /| 00000060 76 69 73 69 74 2e 6a 73 20 2f 6c 6f 61 64 20 2f |visit.js /load /| 00000070 70 75 73 68 20 2f 70 74 6a 20 2f 6a 2e 61 64 20 |push /ptj /j.ad | 00000080 2f 67 61 2e 6a 73 20 2f 65 6e 5f 55 53 2f 61 6c |/ga.js /en_US/al| 00000090 6c 2e 6a 73 20 2f 61 63 74 69 76 69 74 79 20 2f |l.js /activity /| 000000a0 49 45 39 43 6f 6d 70 61 74 56 69 65 77 4c 69 73 |IE9CompatViewLis| 000000b0 74 2e 78 6d 6c |t.xml| ``` |00 70 66 63 7f 73 38 39 65 39 7b|0 8 c d c c c d 8 c d|0 2 b 2 c e 8 2 2 3 2|00 f1 a6 ba b5 fe ad aa f1 bd bf|c 9 8 8 c c c 8 8 9 9|d 2 7 3 2 d 2 8 7 6 6|75 7f 7a 62 39 7b 39 36 78 7f 40|c d 8 c c c c 8 f d c|3 a 2 7 1 3 e d d 4 b|fe bb f1 ad b3 aa b1 b4 8b b7 bb|Col11|Col12||. |Í |. |. |Ì | |. |. |Ì |± |. |.|... Iý« 8Å· yÖð dÑ. 9Á¦ ~.ñ r.ñ wÆþ 9ò o.ñ ZË.|â. .{ .6 .. Â9 Â9 .. .c Íq .8 «S .||¢Þ .¹ .¹ Äþ Ä© Ò· Ñ· Ѷ Ãð È. ..|µ. .p Ìf Íc .. .s .8 Â9 .e Â9 .{|.. .ñ ˦ Òº ̵ Îþ È. Òª .ñ ý Ò¿|Íu .. .z .b Â9 Í{ Â9 .6 .x .. .@|Ãþ Ú» .ñ Ç. Á³ ê α .´ ý. Ô· Ë»|| | | | | | | | | | ||Col22|Col23|Col24|Col25|Col26|Col27|Col28|Col29|Col30|Col31|Col32|Col33|Col34|Col35| |---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---| **Figure 15: Vermilion Strike decrypted string data.** These five chunks of data are either separated by a space or comma, and contain the rest of the configuration data the malware uses when communicating with its C2 server: - DNS servers - GET URLs - POST URLs - Subdomains to use with DNS C2 traffic Finally, the malware parses the beacon configuration. Although the malware uses the same structure as a real Cobalt Strike beacon, it only loads the configuration types shown in Table 3 from the beacon data. ----- Type Name Description 01 BeaconType How to communicate with the C2 02 Port What port to use when communicating with the C2 03 SleepTime How often to check in with the C2 07 PublicKey An RSA public key used to encrypt communication with the C2 08 C2Server A list of server names and GET URL paths to use to check in 09 UserAgent The User-Agent string to use in HTTP communication 10 HttpPostUri The POST URL to use to send responses to the C2 13 HttpPost_Metadata Additional data to set in POST requests to the C2 **Table 3: Vermilion Strike configuration types.** ###### Vermilion Strike setup After loading the configuration, the malware proceeds to initialize the additional values it needs to communicate with the C2. These steps are similar to what a real Cobalt Strike beacon does.[56] The setup consists of the following steps: 1. Generate an array of 16 random bytes 2. Generate a SHA256 of the bytes 3. Use the first half of the SHA256 for AES keys 4. Use the second half of the SHA256 for HMAC keys 5. Load the RSA key from the beacon configuration 6. Collect and encrypt victim machine information: – Random number – PID – OS name – IP address – User name – Host name – Malware version number The version number used in this specific sample of the malware is 1.0.1.LR. |Col1|mu|nic|ate|w|ith|th|e C|2|Col10|Col11|Col12|Col13|Col14|Col15|Col16|Col17|Col18|Col19|Col20|Col21|Col22|Col23|Col24|Col25|Col26|Col27|Col28|Col29|Col30|Col31|Col32|Col33|Col34|Col35|Col36| |---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---| |Port What port to SleepTime How often to|us ch|e ec|wh k i|en n w|co ith|mm th|u e|nic C2|atin|g|wit|h t|he|C2|||||||||||||||||||||| |PublicKey An RSA publ|ic|key|u|sed|to|e|ncr|yp|t c|om|mu|ni|cat|ion|wi|th|the|C|2||||||||||||||||| |C2Server A list of serv|er|na|me|s a|nd|GE|T|UR|L p|at|hs|to|use|to|ch|ec|k i|n|||||||||||||||||| |UserAgent The User-Ag|en|t st|rin|g t|o u|se|in|HT|TP|c|om|mu|ni|cat|ion||||||||||||||||||||| |HttpPostUri The POST U|RL|to|us|e t|o s|en|d r|esp|on|se|s to|th|e|C2|||||||||||||||||||||| |HttpPost_Metadata Additional d|ata|to|se|t in|P|OS|T r|eq|ues|ts|to|the|C|2|||||||||||||||||||||| |le 3: Vermilion Strike configuration types.|||||||||||||||||||||||||||||||||||| ----- ###### Cobalt Strike/Vermilion Strike C2 communication After loading the configuration and performing the additional setup, the malware enters its main processing loop. Each time through the main loop, the malware will attempt to check in with the C2 server and then go to sleep for the time specified in the SleepTime beacon configuration. Depending on the BeaconType value, as previously mentioned, the C2 communication method will change. The malware currently supports hybrid HTTP DNS, HTTPS, and HTTP communication. There is an additional ICMP communication method in [the code but no configuration option to select it. As Intezer noted, this might indicate this code is under](https://www.intezer.com/blog/malware-analysis/vermilionstrike-reimplementation-cobaltstrike/) development. In the case of HTTP or HTTPS communications, a GET request is made to the server to check in. A cookie value is set with Base64-encoded data collected from the victim machine. The server responds to the GET request with any queued-up commands. The commands shown in Table 4 are supported by the malware. Command Name Description 02 shell Execute the command 04 sleep Change how often the beacon calls home 05 cd Change directory on host 10 upload Upload a file to host (first chunk) 11 download Download a file 19 cancel Cancels a download that is currently in progress 39 pwd Displays the current working directory 53 ls List files in a folder 55 drives List drives on current system 67 upload Upload a file to host (subsequent chunks) **Table 4: Vermilion Strike supported commands.** The malware will execute the commands sent to it from the server and then send a POST request back with the requested information. |m g al e ion n. t it s, m nd tio he|u th wa be m Th . A a th s s n co|ni e a re ac et er s I GE e ho m|ca dd wi on ho e is nt|ti iti ll a co d a ez|on on tt nf wi n a er|al em ig ll c d no|se pt ura ha dit te|tu to tio ng ion d, m ne 4|p, c n. e. al thi ad . T ar|the he D T IC s e h e s|m ck ep he M mi to e s up|al in en m P c gh th er po|wa wi di alw o t in e s ver rt|re th ng a mm di er r ed|e th o re u ca ve esp b|nte e n t cu nic te r t o y t|rs C2 he rre at thi o c nd he|it se B nt ion s he s t m|s m rv ea ly m co ck o t alw|ai er co su et de in he a|n an n pp ho is . A G re.|pro d Ty or d un c ET|ce th pe ts in de oo re|ss en v hy r ki q|in go alu br e v ue|g t e, id al st|o ue|Col29|Col30|Col31|Col32|Col33|Col34|Col35| |---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---| ||||T vic w ma|re tim n i nd|qu m n T|est a ab|is chi le|||||||||||||||||||||||||||| ----- ``` File Name : 7129434afc1fec276525acfeee5bb08923ccd9b32269638a54c7b452f5493492 File Size : 238,080 bytes MD5 : 4baec501cd3c6318c8bceb4cf5c8b394 SHA256 : 7129434afc1fec276525acfeee5bb08923ccd9b32269638a54c7b452f5493492 Compiled Time : Wed Jun 26 02:59:19 2019 UTC PE Sections (5) : Name Size MD5 .text 165,888 856639ce9212eb1329c8a59f89f0f97e .rdata 51,200 590ccfa17cf705285509a4ae3ae50f38 .data 7,168 bfcb5a68d595cf49d2b372f35bbaacc5 ``` `.rsrc` `512` 09a004fff9ae1f2b5ff7ded5bcfaf389 ``` .reloc 12,288 f6d8de448cad7e9a2587b75d8894c69d Original DLL : gigabigsvc.dll DLL Exports (1) : Ordinal Name 1 ServiceMain Magic : PE32 executable (DLL) (GUI) Intel 80386, for MS Windows ``` **Figure 16: Vermilion Strike Windows file.** ###### Vermilion Strike Windows and Linux differences As an aside, the Windows version of the malware is almost identical to the Linux version with only a few differences. For instance, when collecting and encrypting victim machine information, the Windows version uses the following malware version numbers: - 1.0.1.WR - W1.0.1 Additionally, before entering the main loop, the Windows version will start a thread that attempts to read information from a named pipe and send the data to the C2 server using standard communication methods. Table 5 shows three additional commands the Windows version understands that are not available in the Linux variant due to differences in how the two operating systems manage named pipes. Command Name Description 20 create_pipe Create a named pipe 21 resume_pipe ResumeThread on the named pipe thread 23 suspend_pipe SuspendThread on the named pipe thread **Table 5: Vermilion Strike commands for named pipes.** These additional commands and threads seem to be related to Cobalt Strike functionality that allows the beacon to be injected into other processes and use a named pipe to communicate back to the main beacon when sending responses to the C2. Although the commands exist for controlling the named pipe thread in Linux, there doesn’t seem to be any ability for the beacon to inject itself into other processes. |52 8b 52 19 88 0 8 DL|5a ce 5a 2 L)|cf b4 cf 01 (|ee cf ee 9 M 8 5 b 0 f GU|e5b 5c8 e5b UTC D5 56 90 fc 9a 6d I)|b0 b3 b0 63 cc b5 00 8d In|89 94 89 9c fa a6 4ff e4 te|23 23 e9 17 8d f9 48 l|cc cc 21 cf 59 ae ca 80|d9 d9 2e 70 5c 1f d7 38|b3 b3 b13 528 f49 2b5 e9a 6,|22 22 29 55 d2 f7f 25 f|69 69 c8 09 b3 de 87 or|63 63 a5 a4 72 d5 b7 M|8a 8a 9f ae f3 bc 5d S|54c 54c 89 3a 5b fa 88 Win|7b 7b f0 e5 ba f3 94 do|45 45 f9 0f ac 89 c6 ws|2f 2f 7e 38 c5 9d|54 54|93 93|49 49|2 2|Col24|Col25|Col26|Col27|Col28|Col29|Col30|Col31|Col32|Col33|Col34|Col35| |---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---| ----- ###### Metadata The Windows version also provides additional metadata that might be useful. First is a PDB path, shown below. A PDB value is a file path stored within a Windows executable that has debugging enabled. This refers back to the original path on the malware developer’s computer where the malware was compiled, which can provide insightful clues to the actor. C:\workspace\spy\cobaltstrike-client-vc2008\Release\gigabigsvc.pdb Second is the compilation timestamps of the beacons and stager binaries. The following unique timestamps are seen on the Windows binaries: - 2019-06-26 02:59:19 - 2019-06-26 02:59:26 - 2020-09-12 14:35:36 - 2020-09-12 14:36:10 The fact that a lot of the compilation timestamps of the samples come from 2019 is a clue that this Cobalt Strike clone might have been written to be compatible with version 3.x. ###### Vermilion Strike compatibility with Cobalt Strike team server Based on the analysis of malware samples, it appears this malware is most compatible with Cobalt Strike 3.x. After testing, a sample can connect and retrieve commands from the server but does not properly send back responses. There appears to be two problems. The first problem is even though the beacon configuration is read and the POST URI decoded, the malware does not use this value. Instead, it selects at random from an array of POST URIs, which are loaded from the .rodata section. When sending responses to the server, it most often gets a 404 error returned, as seen in Figure 17. **Figure 17: C2 POST error.** |l m n a elo \R be ps ble|et W pe el ac o w|ad in r’s ea on f t ith|at do c se s a he v|a t w om \gi nd sa ers|ha s e p ga s m io|t xe ute bi tag ple n 3|mig cu r gs er s .x|ht ta wh vc. b co .|b ble er pd ina me|e u th e t b ri fr|se at he es. o|fu h m T m 2|l. as al he 01|Fir de wa fo 9|st i bu re llo is|s g w wi a c|a P gin as ng lu|D g co u e t|B p en m niq ha|at ab pil ue t t|h, le ed ti his|sh d. , w me C|o Th hi st ob|wn is r ch am alt|ef ca p St|er n s rik|s e|Col29|Col30|Col31|Col32|Col33|Col34|Col35| |---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---| ----- The second issue is that the POST URI is supposed to include a session ID, but the malware just uses a random number for this session ID. The result is that, even if the correct POST URI is picked at random, the server doesn’t process the results because the session ID is unknown. ###### The VMware Threat Analysis Unit Cobalt Strike threat intelligence collection Security practitioners often rely on the reputation of IP addresses to determine if traffic to and from that indicator of compromise (IOC) is malicious. However, the reputation is not effective for catching fresh malware C2 servers. In the example shown in Figure 18, antivirus (AV) engines detected an IP address as [harmless (0/87)[57] on VirusTotal in September 2021, but in the VMware Threat Analysis Unit, we were able to](https://www.virustotal.com/gui/ip-address/52.157.171.98) identify it as a Cobalt Strike team server (C2). **Figure 18: VirusTotal result against one IP address.** We looked at the DNS protocol, which we had reversed, and saw the protocols of high-profile malware families were emulated, especially those used for cyberespionage to discover real-time C2 instances on the internet. We utilized this intelligence to not only detect the threats but to also support incident response cases. The following section describes our findings on these Cobalt Strike threats. ###### Protocol overview and our approach Cobalt Strike is split into a client and server component called a team server. An operator using a client GUI program connects to a team server after authenticating with a password through the TLS protocol. A Cobalt Strike stager then downloads a main RAT module, the beacon, from the team server. The beacon will receive task (command) information from the team server and send back the results of the executed command. Both stager and beacon protocols for C2 communications are implemented in HTTP/HTTPS/DNS. Additionally, Cobalt Strike allows third-party programs to act as a communication layer for the beacon’s [payload. In those cases, the beacon session is forwarded to a team server’s External C2[58] service function,](https://www.cobaltstrike.com/help-externalc2) [using a third-party client and controller. (For more Cobalt Strike protocol details, please see our presentation[59]](https://jsac.jpcert.or.jp/archive/2021/pdf/JSAC2021_201_haruyama_jp.pdf) for the Japan Security Analyst Conference (JSAC) 2021.) |os ev on it ati o F 2|ed en ID C on we ig 02|t if is o of ve ure 1,|o i th u b IP r, t 1 bu|ncl e c nk al a he 8, t i|ud or no t dd r an n t|e re wn St re ep tiv he|a s ct . ri ss uta iru V|es PO ke es ti s ( Mw|sio ST t to on A a|n U hr de is V) re|ID RI e te no en Th|, b is at rm t e gi re|ut pi i in ff ne at|th ck nt e i ect s d An|e ed el f t iv et al|ma at li raf e f ec ysi|lw ra ge fic or te s|ar n n to ca d a Un|e j do c a tc n I it,|ust m, e nd hin P w|u th co fr g ad e w|se e ll om fre dr er|s a ser ec t sh es e|ra ve ti hat s a ab|nd r o s le|o n to|m|Col29|Col30|Col31|Col32|Col33|Col34|Col35| |---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---| ----- To identify Cobalt Strike team servers, we focused on the staging process of each protocol, **Beacon Download** (HTTP/HTTPS/DNS/External C2) to ensure we: **(HTTP/HTTPS/DNS)** **Stager** **(Downloader)** **Client Authentication** - Did not circumvent any technological measure, **(TLS)** such as authentication for the discovery. The client authentication protocol was not in **(HTTP/HTTPS/DNS)Task Execution** **Team Server** our options because the emulation could be a **Beacon (RAT)** login attempt by an unauthorized user to the team servers. **External C2** **Named** **(TCP)** - Avoided false positives. Previous research **Pipe** [(e.g., Fox-IT[60] and ZoomEye[61]) didn’t](https://blog.fox-it.com/2019/02/26/identifying-cobalt-strike-team-servers-in-the-wild/) differentiate the Cobalt Strike team servers and NanoHTTPD servers because they rely solely **Third-Party** on the HTTP response header data. Similarly, **Third-Party** **Command & Control** **Third-Party** we obtained responses from the team servers **Client** **Controller** by sending requests based on the beacon protocol, such as HTTP/HTTPS GET requests, **Figure 19: Cobalt Strike protocols overview.** with the correct URI paths or arbitrary DNS A record queries. The team servers answered with a 200 OK status code in HTTP/HTTPS or a dns_idle value in DNS. However, we knew that a simple confirmation, without RSA/AES encryption in the beacon protocol would produce many false positives. - Discovered team servers silently. We emulated the beacon session encryption and then downloaded task information from the servers. However, once the emulation code checked in at the servers, an entry was created on the Cobalt Strike GUI console. Such a noticeable method is unfavorable for this purpose. [Therefore, we took the same approach as the one used by the Cobalt Strike developers[62] to emulate the stager](https://blog.cobaltstrike.com/2019/02/19/cobalt-strike-team-server-population-study/) protocol. Our implementation downloads beacon executables from Cobalt Strike team servers, and then decodes and parses their configuration blocks to obtain further information. The protocol requires no authentication, and the method will not lead to any false positives. We recognize that some security researchers and organizations analyze the Cobalt Strike team servers in the wild, using the stager protocol, but that doesn’t cover DNS and External C2 protocols, and threat actors tend to prefer them to HTTP/HTTPS. Additionally, since version 3.5.1, Cobalt Strike has an option to disable the hosting of payload stages for HTTP/ HTTPS/DNS protocols (except External C2). Specifically, users are able to disable the stager protocol by just [setting a line in the Malleable C2 Profile:[63]](https://www.cobaltstrike.com/help-malleable-c2) |co e: ur a e an y y, rs|l, e, d|Col3|Na Pi|(Do Be med pe Th|Sta wnl aco ird- Cli|ger oad n ( Par ent|er RA ty|) T)|(H|B (HT Ta TT|eaco TP sk E P/H|n D /HT xec TTP|ow TPS utio S/D|nloa /D n NS|d NS) )|Tea Thir Co|m S d-P ntro|erver Exte ( arty ller|Col20|Cli|ent|Au (T|then LS)|tica|tio|n|(O|Col29|Col30|)|Col32|Col33|Col34| |---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---| ||||||||||||||||||||rnal TCP)|C2||||||||Cli pe|ent rator||||| ||||||||||Com|Thi ma|rd- nd|Part & C|y ontr|ol|||||||||||||||||||| ``` set host_stage "false"; ``` When disabled, it is impossible to detect the server by our method, but it gives Cobalt Strike users an alternative mechanism to deliver their beacons. ----- ###### Observations since February 2020 Between February 2020 to November 2021, we discovered more than 14,000 active Cobalt Strike team servers on the internet. Populations by protocol, version and customer ID The percentage of each stager/beacon protocol is shown in Figure 20. The most popular protocol is HTTPS; the HTTP ratio increased 31 percent in January 2021 to 37 percent in November. We hypothesize Cobalt Strike users try to avoid a detection technique based on TLS [handshakes, called JARM.[64]](https://github.com/salesforce/jarm) External C2 1% |we er col|di ID is|sc sh|ov o|er wn|ed in|m Fi|or gu|e t re|ha 2|n 1 0.|4, Th|0 e|00 mo|ac st|tiv po|e p|Co ula|ba r p|lt S ro|tr to|ik co|e t l is|ea H|m TT|P|S;|Col28|Col29|Col30|Col31|Col32|Col33|Col34|Col35| |---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---| Our discovery system guesses Cobalt Strike versions based on the collected beacon’s configuration values. For example, if a SETTING_WATERMARK value (i.e., the [customer ID[65]) is included in the configuration, the version](https://www.cobaltstrike.com/help-authorization-files) must be 3.9 and later at minimum. In addition, a SETTING_ DOMAIN_STRATEGY value indicates that the version is 4.3 and later. From our sample datasets, we found that close to 90 percent are version 4 and later (Figure 21). Regarding customer IDs, we found at least five customer Cobalt Strike IDs were cracked and leaked: - 1873433027 - 305419896 - 16777216 - 1359593325 **Figure 20: Population by protocol.** - 0 (trial) 3.9-3.13 3.8 and below 2% 0% 3.9-3.13 2% 6% 8% 16777216 1% 1873433027 305419896 25% 16% 0 (trial and cracked) **Figure 21: Cobalt Strike server population by version.** **Figure 22: Population by customer ID.** ----- As shown in Figure 22, the total percentage of cracked and leaked customer IDs is 56 percent. This means that more than half of the observed Cobalt Strike users are using illegitimately obtained versions of the commercial software. Additionally, it should be noted that cracked trial license cases are increasing lately. Since Cobalt Strike version [3.6, the encryption of the beacon protocol is disabled[66] in the trial license. It can be checked by looking at the](https://blog.cobaltstrike.com/2015/10/14/the-cobalt-strike-trials-evil-bit/) config value SETTING_CRYPTO_SCHEME. If it's 1, it's disabled. However, we noticed there are a lot of team servers with the value 0, even if the customer ID is 0 and the version is newer than 3.6, such as in the following parsed config output: ``` ... word CRYPTO_SCHEME (1 = disable encryption) at 0x746: 0 (0x0) ... dword WATERMARK at 0x798: 0 (0x0) ... ``` We counted these servers as a part of the cracked customer IDs in Figure 22. Change in the number of team servers obtained by a single scan We discovered Cobalt Strike team servers targeting multiple protocols and ports. In Figure 23, we display the changes in the result of a single scan, which focuses on typical ports (HTTPS/443, HTTP/80, DNS/53 and ExternalC2/2222), and a scan that covers other ports as well. 900 800 700 600 500 400 300 200 100 0 Feb-20 Mar-20 Apr-20 May-20 Jun-20 Jul-20 Aug-20 Sep-20 Oct-20 Nov-20 Dec-20 Jan-21 Feb-21 Mar-21 Apr-21 May-21 Jun-21 Jul-21 Aug-21 Sep-21 Oct-21 Nov-21 HTTPS/443 HTTP/80 DNS/53 ExternalC2/2222 **Figure 23: Change in the result of a single scan.** Since December 2020, the numbers look to decrease. However, we understand a part of Cobalt Strike users just disabled the stager protocol, rather than halting its usage. Security researchers should pay attention to the stager-disabled team servers to detect any changes. |f c us tria dis|ra er l li ab|ck s a ce le|ed re ns d66 's a t|a u e in di nd 0x|nd sin cas th sa th 74|le g es e ble e v 6:|ak ille a tri d. er 0|ed gi re al l H sio (|cu tim in ice ow n 0x|st a cr n e is 0)|om tel eas se ver ne|e y in . It , w w|r ID obt g l ca e er t|s ai at n no h|is ne ely be tic an|56 d . S c ed 3.|p ver inc hec th 6,|er si e k e su|ce on Co ed re ch|nt. s o b by ar as|Th f t alt lo e a in|is he St ok lo th|m rik in t o e|ea e v g a f t fol|ns er t t ea lo|th sio he m win|at n g|Col29|Col30|Col31|Col32|Col33|Col34|Col35| |---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---| |it' ID ti|s 1 is on|, it 0 ) a||||||||||||||||||||||||||||||||| ----- Domain fronting observation (e.g., Microsoft Azure, Fastly) [Domain fronting[67] is a technique that obfuscates the intended destination of HTTPS traffic. Domain fronting](https://attack.mitre.org/techniques/T1090/004/) takes advantage of routing schemes in content delivery networks (CDNs) and other services. Specifically, the Cobalt Strike beacon configuration has different hostnames in C2 hostname (SETTING_ DOMAINS) and HOST header values. Users can set the header values in either of two locations: in the [HTTP config or the GUI menu. The Malleable C2 Profile[68] setting is part of the HTTP transform data](https://blog.cobaltstrike.com/2017/02/06/high-reputation-redirectors-and-domain-fronting/) of the config, while the config value SETTING_HOST_HEADER is part of the GUI menu setting. The latter setting will overwrite the former one. We found the most popular CDN abused by Cobalt Strike was Microsoft Azure, followed by Fastly. CDN Host header value C2 hostname examples Microsoft Azure *.azureedge.net *.microsoft.com, *.msn.com, *.skype.com, *.visualstudio.com, *.azure.com Fastly *.global.prod.fastly.net *nytimes.com, *yelp.com, *bbc.com, *usatoday.com, *forbes.com, *theguardian.com, *cnn.com, *stackexchange.com, *reddit.com **Table 6: Azure/Fastly domain fronting settings observed in Cobalt Strike team servers.** |Col1|Az tes nt rat an C2|ur th de io se P|e, e liv n h t t ro|Fa int ery as he file|stl en n di h 68 HE ik me om|y) de et ffe ea se A e e, *|d wo re de tti DE wa xa .m|de rk nt r v ng R s m sn|sti s ( ho al is is Mic ple .co|na CD st ues pa par ro s m,|tio N na in rt t so *.|n s) m e of of ft sky|of an es ith th the Az pe|H d in er e G ur .co|TT oth C2 of HT UI e, m|PS er h tw TP m fol, *.|tra se ost o tr en lo vis|ff rv n lo an u we ual|ic. ice am ca sf se d stu|D s. e ( tio or tti by di|om SE ns m d ng F o.c|ai T : in at . ast om|n f TIN th a ly., *|ro G e .az|nti _ ur|ng e.c|om|Col29|Col30|Col31|Col32|Col33|Col34|Col35|Col36| |---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---| ||_H e. Co 2 mi|O ba ho cro|ST lt stn so|_ Str a ft.c|||||||||||||||||||||||||||||||| |stly *.global.prod.fastly.net * *t|nyt he|im gu|es. ard|co ia|m, n.c|*ye om|lp, *|.co cn|m, n.c|*b om|bc, *|.co sta|m, ck|*u exc|sa ha|tod ng|ay. e.c|co om|m,, *|*f re|orb ddi|es t.c|.co om|m,|||||||||||| We found multiple Azure-fronted team servers with cracked and leaked customer IDs that were likely to be managed by threat actors, not red teamers. VMware researchers worked directly with Microsoft in January 2021 and, two months later, [Microsoft stated[69] that the company](https://www.microsoft.com/security/blog/2021/03/26/securing-our-approach-to-domain-fronting-within-azure/) decided to make a change to their policy to ensure that domain fronting will be stopped and prevented within Azure. Since then, the new Azure-fronted cases have been on a downward slope. From August to October 2021, they have been reduced to zero. Based on our monitoring, we hypothesize that Cobalt Strike users that were using Azure have migrated to Fastly or other services hiding a real IP address, such as Cloudflare Workers. 0 20 40 60 80 100 120 140 160 Microsoft Azure (until Jan. 2021) Microsoft Azure (since Feb. 2021) Fastly (until Jan. 2021) Fastly (since Feb. 2021) **Figure 24: The change in number of new domain-fronted team servers.** ----- ###### Attribution to the specific threat actors We parsed configuration blocks of beacons downloaded from team servers to categorize them into clusters based on config values. The clusters could be attributed to specific threat actors or campaigns. We primarily focused on two values in the configuration for this purpose: SETTING_PUBKEY and SETTING_WATERMARK. SETTING_PUBKEY is an RSA public key in a DER format utilized in the beacon protocol encryption. The RSA key pair is created as a file, .cobaltstrike.beacon_keys, when starting and logging on to a team server for the first time. After that, if the team server directory is copied to another host, the copied one will have the same key pair file and the public key will be reused. Therefore, the two servers, whose beacons have the same public key, are likely to be managed by the same person or organization, unless the key pair file is leaked. If [the file is leaked, the number of servers using the same public key can be huge.[70] We can exclude such a key](https://blog.nviso.eu/2021/10/21/cobalt-strike-using-known-private-keys-to-decrypt-traffic-part-1/) for clustering. SETTING_WATERMARK is a customer ID extracted from the authorization file, cobaltstrike.auth on a team [server. According to Cobalt Strike’s developers,[71] the ID is assigned to every team server of Cobalt Strike,](https://www.cobaltstrike.com/help-authorization-files) version 3.9 and later, and is changed when running the update program. If a team server’s WATERMARK is matched with another one, it means they are operated by a single actor. Even if the software package is not valid (leaked or cracked), the activities utilizing an invalid package are probably malicious. This is how we can differentiate servers managed by valid customers and ones abused by criminals. Other than these values, some values in the configuration, such as HTTP header information, and the jar path hash value (SETTING_PROCINJ_STUB) may be beneficial for attribution work. The undisclosed team servers owned by the threat actors (e.g., APT41) Based on the SETTING_PUBKEY sharing, we were able to identify the undisclosed team servers owned by APT41 in the two attack campaigns. Case 1: Campaign ColunmTK [Group-IB[72] discovered and shared a cyberattack on Air India and attributed it with moderate confidence to](https://blog.group-ib.com/colunmtk_apt41) APT41 in June 2021. The campaign was codenamed ColunmTK. Based on the published network indicators, we found two undisclosed Cobalt Strike team servers. The identification procedure is simple: 1. Search for the known IP addresses/domains in our datasets. 2. Obtain customer ID and public key MD5 values from the records. 3. Search for other IP addresses sharing the same values. In this case, we utilized the four public key MD5 values extracted from three known servers. The customer IDs were not available for clustering as they were all cracked and leaked. |Col1|s ow at th DE on ry T m th ra rs,|nl tri is R _ is he e e cte 71 t in|oa bu pu fo ke co ref pe sa d he g t|de te rp rm ys, pi or rso me fro I he|d d t os at w ed e, n p m D i u|fro o e: ut he to th or ub th s a pd|m sp S iliz n a e t or lic e ssi at|te eci ET ed sta no wo ga ke aut gn e p|am fic TI in rti th s ni y ho ed ro|s th NG th ng er er zat ca ri t gr|er re _ e a ho ver io n b zat o e am|ve at PU be nd st, s, n, e io ve .|rs ac BK ac lo th w un hu|to to E on gg e ho les ge|ca rs Y a p in co se s t .70 c am a|te or n rot g o pi be he W ob s m|go ca d S oc n ed ac k e alt er ser|riz m ET ol to on on ey ca str ve ve|e t pai TI en a t e s p n ik r o r’s|he gn N cr ea wil ha air ex e.a f C W|m s. G_ yp m l h ve fil clu ut o A|in W W tio se av th e is de h o bal TE|to e AT n. rv e t e le s n t S R|clu pri E T er he sa ak uc a t tri MA|st m RM he fo s me ed h a ea ke R|er ari A RS r t am . I k m , K i|s ly RK A he e f ey s|.|Col30|Col31|Col32|Col33|Col34|Col35|Col36| |---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---| ||||||||||||||n fi ry If a|le, te te|||||||||||||||||||||| |d when ru|nn||||||||||||||||||||||||||||||||||| ----- C2 IP address Protocol/port First seen Last seen Customer ID Public key MD5 104.224.169.214 HTTP and 2020/03/16 2020/09/03 0 (trial and DNS/5353, cracked), HTTP/80, 305419896 HTTPS/443, (cracked and DNS/53 leaked) 185.118.164.198 HTTPS/443 2021/01/12 2021/01/12 305419896 (cracked and leaked) 185.118.166.66 HTTPS/443, 2020/12/06 2021/04/09 305419896 HTTPS/8443 (cracked and **Table 7: Known team servers reported by Group-IB and observed by the VMware Threat Analysis Unit system.** By using the public key MD5 values, we obtained two undisclosed server IPs, which are shown in Table 8. We were able to even catch a new server (45.144.31.31) deployed after the Group-IB report publication. C2 IP address Protocol/port First seen Last seen Public key MD5 149.248.62.83 HTTPS/443 2020/04/04 2020/04/04 90419b03b90efe0c2c708294b40ced50 45.144.31.31 HTTPS/8443 2021/06/14 2021/06/14 9cdb3fca6156c6cbed2f01d6431b3dfb **Table 8: Two undisclosed servers sharing the public keys.** Case 2: Cobalt Strike loader used by APT41 [LAC,[73] a cybersecurity company in Japan, reported the campaign by APT41 using Cobalt Strike loaders in May](https://www.lac.co.jp/lacwatch/report/20210521_002618.html) 2021. Our system detected seven other servers, which are likely to be managed by the same actor. |Col1|6|Col3|La 20|st 20|se /0|en 9/0|3|( l|Cu 0 (t cra 30 cra ea|st ria ck 541 ck ke|om l a ed) 98 ed d)|er nd, 96 an|ID d|Col15|P 9 b 6 3|ub 04 40 4e d7|lic 19b ce 69 d9|k 0 d5 b0 da|ey 3b9 0, 7e1 4|M 0e 59|D5 fe 40|0c bd|2c7 b2|08 1e4|29 4b|4 d|Col28|Col29|Col30|Col31|Col32|Col33|Col34|Col35|Col36| |---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---| |5.118.164.198 HTTPS/443 2021/01/12|||20|21/|01/|12||( l|30 cra ea|541 ck ke|98 ed d)|96 an|d||9 d|96 b6|83 1cd|53 6|3be|31|7f5|13|a70|f4|0fb|­|||||||||| |5.118.166.66 HTTPS/443, 2020/12/0 HTTPS/8443|6||20|21/|04|/0|9|( l|30 cra ea|541 ck ke|98 ed d)|96 an|d||9 4|cd 31b|b3f 3d|ca fb|615|6c|6c|be|d2f|01|d6||||||||||| |le 7: Known team servers reported by Group-IB an using the public key MD5 values, we obtai|d ne|obs d|er tw|ved o u|by n|th dis|e V clo|M se|wa d|re se|Thr rv|ea er|t A IPs|nal,|ysi wh|s U ich|nit a|sy re|ste sh|m. ow|n|in|Ta|bl|e 8|.|We||||||||| 185.118.166.205 DNS/53 2020/12/12 2021/09/11 305419896 (cracked and leaked) df50953714f29628a7f6a6c 97eb0bc2e **Table 9: Known team servers reported by LAC and observed by the Threat Analysis Unit system.** ----- |Col1|Col2|Col3|Col4|Col5|Col6|Col7|Col8|Col9|Col10|Col11|Col12|Col13|F 2|irs 02|t s 1/0|ee 5/|n 20|Col19|Col20|Col21|Col22|La 20|st 21/|se 06|en /0|3|Col28|Col29|Col30|Col31|Col32|Col33|Col34|Col35|Col36|Col37| |---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---| |18|5.250.151.18 HTTP/80||||||||||||2|02|0/|12/|31|||||20|20|/12|/31|||||||||||| |45|.142.214.242 HTTPS/443, HTTP/80,|HT|TP|S/|844|3,|D|NS|/53||||2|02|1/0|4/|25|||||20|21/|07|/0|2||||||||||| |45|.142.214.56 HTTPS/443, HTTP/80||||||||||||2|02|1/0|6/1|8|||||20|21/|07|/19|||||||||||| |45|.67.229.168 HTTPS/443||||||||||||2|02|0/|12/|03|||||20|20|/12|/0|3||||||||||| |45|.153.231.194 DNS/53||||||||||||2|02|1/0|2/|03|||||20|21/|02|/0|3||||||||||| |19|4.156.98.214 HTTP/80||||||||||||2|02|1/0|1/2|6|||||20|21/|01/|26|||||||||||| |Tab Mo tea Ide We|le 10: Seven undisclosed servers sharing the public reover, it should be noted that the earliest m server discovery, using protocol emulat ntifying potential targets collected manual proxy settings of the be|ke se ion ac|y rv s, on|531 er en co|c72 w a nf|0a as ble ig|ae ac s u ur|6e tiv s ati|05 e to on|3b9 at ta s f|db le ke ro|9b ast pr m|e8 si oa tea|e7 x cti m|b5 mo ve s|6f78 nt c erv|f. hs ou er|ah nte s.|ea rm Th|d e e n|of as u|bo ur mb|th es. er|re of|p se|ort tti|s. ng|Th s i|e s|||||||| |sm use Vi Fi|all; however, they can be useful for identifying the victim organizations, based on the internal domain name, rname and password. The victim information, based on the proxy settings, is listed in Table 11. ctim industry Victim country Time period Cracked/leaked customer ID? nancial services ES 2020/03-2020/06 No|||||||||||||||||||||||||||||||||||| |V|ertical transportation CH 2020/04 No|||||||||||||||||||||||||||||||||||| |A|utomotive DE 2020/04-2020/08 No|||||||||||||||||||||||||||||||||||| **Table 11: Victim information included in the manual proxy configuration.** ----- Most team servers with the settings were likely to be owned by red teams, judging from the customer IDs. We contacted the victims and shared our findings – the team server had a cracked/leaked customer ID and was active at that time – so they could take steps to address the ongoing attack that was happening. ###### Detecting and mitigating the threat RATs, such as Cobalt Strike and Vermilion Strike, pose a significant threat to enterprises. They are often used as the first stage of an attack, delivering additional information or even malware that allows threat actors to pivot and spread to other internal infrastructure. RATs typically gain an initial foothold via simple attacks, such as phishing emails. We have discovered Cobalt Strike team servers in the wild for more than a year and a half. The fact that more than half of the servers have cracked and leaked customer IDs tells us that Cobalt Strike has become a commodity tool among criminals. A robust combination of NDR software and EDR solutions can help stop these attacks before they begin. Looking for unknown applications executing in the environment or abnormal network connections is often an indicator of something larger going on. By actively monitoring and locking down the environment with NDR and EDR solutions, these malicious applications can be stopped before they have a chance to do real harm. |ly t – to ik io re rs ked m n t|o th ad e, nal . R in c bin he|be e t dr po in A th us at e|o ea es se fo Ts e to io nv|wn m s t a rm ty wil me n o iro|ed se he sig ati pic d f r I f n|b rv o nif on all or Ds ND me|y r er ng ic o y g m te R nt|ed ha oin an r e ai or lls so or|te d g t th ve n e t u ftw ab|a a c att re n an ha s t ar n|ms ra ac at ma ini n ha e or|, ju ck k t to lw tia a y t C an ma|d ed ha e ar l f ea ob d l n|gin /le t nte e t oo r a al ED et|g ak wa rp ha th nd t S R wo|fro ed s h ris t a old a tri sol rk|m c ap es llo vi ha ke ut co|th us p . T w a s lf. ha ion n|e c to eni he s t im T s s ne|us me ng y hre pl he be ca cti|to r I . ar at e fa co n h on|m D e o a att ct m el s i|er an fte cto ac tha e a p s s o|ID d n rs ks, t to fte|s. wa us to s mo p n|W s ed uc re|e h|Col29|Col30|Col31|Col32|Col33|Col34|Col35| |---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---| ----- #### VMware recommendations Organizations need to think of security as an inherent and distributed part of the modern enterprise, which must be incorporated into all aspects of the environment. Protecting multi-cloud environments starts with complete visibility into all workloads with detailed system context that makes it easier to understand and prioritize mitigation efforts. Information from all sources must be combined in an intelligent fashion that adds value, while enabling the sharing of this contextual data across teams to reduce silos. This requires an EDR solution that can monitor the actions performed by processes on cloud workloads and implement effective segmentation to contain risks. In addition, organizations need an NDR system that can recognize network-based evidence of attacks and malicious lateral movements to ideally block the malware before it can take hold of the target hosts. A secure multi-cloud environment requires securing all workload access and communications, both inside and across multiple clouds. Easily operationalizing security across clouds requires a scale-out architecture with software that gives the underlying infrastructure—firewalls, network detection and response, meshes, and load balancers—the same elasticity as modern, distributed applications. A Zero Trust strategy can help organizations embed security throughout their infrastructure. Zero Trust offers a connected approach—joining users, devices, workloads and networks—to help organizations systematically address the threat vectors that make up their attack surface. Organizations can ensure they are implementing control points and distributing security across the infrastructure to better protect data and operations. With visibility, context, actionable insights, and control points embedded throughout the environment, organizations can start to spot and stop many of today’s threats before they can even get started. ###### How VMware can help VMware can deliver security as a built-in distributed service across your control points of users, devices, workloads and networks. With VMware, you can implement Zero Trust with fewer tools and silos, and scale response with confidence, speed and accuracy. When security becomes intrinsic, you reduce your attack surface to mitigate security risk, ensure compliance, and simplify security operations. With VMware Security, you can deliver the speed and security required of the modern enterprise. You can transition to next-gen systems and modern applications, without increasing security complexity, and with dramatically fewer blind spots or choke points. Through vendor, agent and tool consolidation, you can achieve better security outcomes and deliver better employee and customer experiences, while spending less time on administrative tasks. |Col1|Col2|Col3|Col4|Col5|Col6|Col7|Col8|Col9|Col10|Col11|Col12|Col13|Col14|Col15|Col16|Col17|Col18|Col19|Col20|Col21|Col22|Col23|Col24|Col25|Col26|Col27|Col28|Col29|Col30|Col31|Col32|Col33| |---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---| |||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||| ||||||||||||||r d t i n i D v k h||e o d o f s a l|||k a w . h i e e h||||||||||||||| ----- With VMware, you operationalize more of your security through your IT and development teams by creating a common source of truth and dramatically increasing your capacity to protect and defend your infrastructure. The authoritative context from the visibility, depth and accuracy of VMware’s data collection enables security teams to confidently respond to events occurring within the organization’s assets. This allows an organization’s most critical assets—its people—to focus on high-value activities, using VMware’s intelligent risk correlation with proactive prevention, detection and response capabilities. VMware Security provides many capabilities to protect organizations from advanced threats targeting multi-cloud environments, such as ransomware, cryptominers, and remote access tools, as described in this threat report: - Organizations focusing on protecting end-user solutions can utilize VMware Workspace ONE®, VMware Horizon®, and VMware Carbon Black Cloud[™] to stop advanced threats from entering the environment. - VMware vSphere®, VMware NSX® Advanced Threat Prevention[™], VMware Carbon Black Cloud, CloudHealth® Secure State[™], VMware Tanzu®, VMware vRealize® Suite, and VMware NSX provide organizations with robust capabilities to protect against, detect and respond to advanced threats in multicloud environments. By partnering with VMware, organizations can capitalize on enterprise modernization efforts, continuously incorporating security into all aspects of the technology stack to accelerate Zero Trust strategies and achieve a more effective security posture. |ur ea ep rin ig on to ar se ™ d u® tec|se sin th g h- se p e, r s to Th , V t|cu g an wit val c ro cr olu st re M ag|rit yo d hi ue ap te yp tio op at w ain|y t ur ac n t a ab ct to n ad Pr are st,|hro ca cu he cti ilit or mi s c va ev v d|u p rac or viti ies ga ne an nc en Re et|gh aci y ga es . niz rs, ut ed tio ali ect|yo ty of ni , u at a iliz t n™ ze a|ur to V za sin io nd e hre , ® nd|IT pr Mw tio g ns re VM at VM Sui re|a ot ar n’s V fro m w s f w te sp|nd ec e’ a Mw m ot ar ro ar , a on|d t a s d ss ar a e a e m e C nd d|ev nd at ets e’ dv cc Wo en ar V to|elo d a c . T s in an es rk te bo M ad|p efe oll hi te ce s t sp rin n wa va|me nd ec s a lli d oo ac g t Bl re nc|nt y tio llo ge thr ls e he ac N ed|te ou n ws nt ea , a ON e k C SX th|am r i en a ris ts s d E nv lo pr re|s nfr ab n o k c ta e ®, iro ud ov at|by as le rg or rg scr V nm , id s i|cr tru s s an re eti ib Mw e e n|ea ct ec iz lat ng ed ar nt. mu|tin ur uri ati ion in e lti-|g e. ty on th|a ’s is|Col29|Col30|Col31|Col32|Col33|Col34|Col35| |---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---| ----- #### References 1 W3Techs. “Usage statistics of operating systems for web sites.” Dec. 2021. 2 Microsoft. "HAFNIUM targeting Exchange Servers." March 2, 2021. 3 Cybersecurity and Infrastructure Security Agency. "Alert (AA21-291A BlackMatter Ransomware." Oct. 18, 2021. 4 CBT Nuggets. "Why Linux runs 90 percent of the public cloud workload." August 10, 2018. 5 Federal Bureau of Investigation. "Ransomware Actors Use Significant Financial Events and Stock Valuation to Facilitate Targeting and Extortion of Victims.” Nov. 1, 2021. 6 VMware. "Deconstructing Defray777 Ransomware." Threat Analysis Unit. March 11, 2021. 7 Mandiant. "Shining a Light on Darkside Ransomware Operations.” Jordan Nuce, Jeremy Kennelly, Kimberly Goody, Andrew Moore,Brendan McKeague, Jared Wilson. May 11, 2021. 8 VMware. “HelloKitty: The Victim’s Perspective.” Threat Analysis Unit. Sept. 9, 2021. 9 VMware. "Moving Left of the Ransomware Boom." Oct. 11, 2021. 10 Github. "trendmicro / telfhash." 11 Github. "mandiant / capa." 12 Security Affairs. "HelloKitty ransomware now targets VMware ESXi servers." Pierluigi Paganini. July 15, 2021. 13 Intezer. “Operation ElectroRAT: Attacker Creates Fake Companies to Drain Your Crypto Wallets.” Avigayil Mechtinger. Jan. 5, 2021. 14 Wired. "Hack Brief: Hackers Enlisted Tesla's Public Cloud to Mine Cryptocurrency." Lily Hay Newman. Feb. 20, 2018. 15 Palo Alto Networks. "Highlights from the Unit 42 Cloud Threat Report, 2H 2020." Oct. 6, 2020. 16 Investopedia. “The 6 Most Private Cryptocurrencies.” Shobhit Seth. July 4, 2021. 17 Miner Daily. "How Much Does it Cost to Mine a Bitcoin?" Sam Ling. May 4, 2021. 18 Github. "xmrig / xmrig." 19 hex-rays. "IDA F.L.I.R.T. Technology: In-Depth." 20 Github. "goretk / redress." 21 Github. "eliben / pyelftools" 22 hex-rays. "F.L.I.R.T." 23 Github. "goretk / redress" 24 Github. "mandiant / capa" 25 Github. "trendmicro / telfhash." 26 ebpf.io. 27 Github. "aquasecurity / tracee." 28 virustotal.com 29 Bleeping Computer. “REvil ransomware’s new Linux encryptor targets ESXi virtual machines.” Lawrence Abrams. June 28, 2021. 30 ARS Technica. "FBI, others crush REvil using ransomware gang's favorite tactic against it.” Tim De Chant. Oct. 22, 2021. 31 Crowdstrike. "Hypervisor Jackpotting, Part 1: CARBON SPIDER and SPRITE SPIDER Target ESXi Servers with Ransomware to Maximize Impact." Eric Loui-Sergei Frankoff. Feb. 26, 2021. 32 VMware. "Critical Infrastructure Remains at Risk Following Ransomware Attack.” Rick McElroy. May 11, 2021. 33 Mandiant. "Shining a Light on Darkside Ransomware Operations." Jordan Nuce, Jeremy Kennelly, Kimberly Goody, Andrew Moore, Brendan McKeague, Jared Wilson. May 11, 2021. 34 Insikt Group. "BlackMatter Ransomware Emerges as Successor to DarkSide, REvil." July 27, 2021. 35 VMware. "Deconstructing Defray777 Ransomware." Threat Analysis Unit. March 11, 2021. 36 Bleeping Computer. “RansomEXX Ransomware Linux encryptor may damage victims’ files.” Lawrence Abrams. Sept. 30, 2021. 37 Security Affairs. "HelloKitty ransomware now targets VMware ESXi servers." Pierluigi Paganini. July 15, 2021. 38 HIPPAA Journal. "Vice Society Ransomware Gang Attacks United Health Centers of San Joaquin Valley." Sept. 27, 2021. 39 Trend Micro. “Erebus Resurfaces as Linux Ransomware.” Ziv Chang, Gilbert Sison, Jeanne Jocson. June 19, 2017. 40 Github. "tarcisio-marinho / GonnaCry." 41 Anomali Threat Research. "The eCh0raix Ransomware." July 10, 2019. |sit ch 2 (A clou e S at A erat nal 1, 2 wa om to hre obh|es.” , 2 A21 d ign na ion ysi 021 re E pan Mi at it S|De 021 -29 wor ific lysi s.” s U . SX ies ne Rep eth|c. . 1A klo ant s U Jor nit. i se to Cry ort . J|202 Bla ad. Fin nit. da Se rve Dra pto , 2 uly|1. ckM " A an M n N pt. rs. in Y cur H 2 4, 2|at ugu cial arch uce 9, 2 " Pi ou ren 020 02|ter st 1 Ev 11, , J 02 erlu r C cy. ." 1.|Ran 0, ent 20 ere 1. igi ryp " Li Oct|so 201 s a 21. my Pa to ly H . 6,|mw 8. nd Ke gan Wal ay 20|are Sto nne ini lets Ne 20.|." O ck V lly, . Ju .” wm|ct. alu Ki ly 1 Avi an|18 ati mb 5, 2 gay . Fe|, 20 on erly 02 il M b.|21. to F Go 1. ec 20,|aci od htin 20|lita y, A ger 18.|te T nd . Ja|arg rew n.|eti M 5, 2|ng oor 02|and e,B 1.|Ex ren|tor da|tio n|n|Col29|Col30|Col31|Col32|Col33|Col34|Col35| |---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---| ----- 42 Bleeping Computer. "New eCh0raix Ransomware Brute-Forces QNAP NAS Devices." Sergiu Gatlan. July 10, 2019. 43 Github. "xmrig / xmrig." 44 Cujo AI. “The Sysrv Botnet and How it Evolved.” September 22, 2021. 45 Sysdig. "THREAT ALERT: Crypto miner attack – Sysrv-Hello Botnet targeting WordPress pods." Stefano Chierici. August 26, 2021. 46 Palo Alto Networks. "Hildegard: New TeamTNT cryptojacking Malware Targeting Kubernetes." Jay Chen, Aviv Sasson, Ariel Zelivansky. Feb. 3, 2021. 47 Anomali Threat Research. “Inside TeamTNT’s Impressive Arsenal: A Look into a TeamTNT Server.” Tara Gould. Oct. 6, 2021, 48 hex-rays. "IDA F.L.I.R.T. Technology: In-Depth." 49 Bitdefender. “How We Tracked a Threat Group Running an Active Cryptojacking Campaign." July 14, 2021. 50 AT&T Business. “AT&T Alient Labs analysis of an active cryptomining work.” Fernando Dominguez. Jan. 9, 2020. 51 Unit 42, Palo Alto Networks. "Exposing a Cryptojacking Campaign That's Operated for Two Years." Nathaniel Quist. Feb. 17, 2021. 52 Aqua Security. “Kinsing Malware Attacks Container Environments.” Gal Singer. April 3, 2020. 53 Intezer. "Vermilion Strike: Linux and Windows Re-implementation of Cobalt Strike." Avigayil Mechtinger, Ryan Robinson, Joakim Kennedy. Sept. 13, 2021. 54 Github. "darkr4y / geacon." 55 Github. "gloxec / CrossC2." 56 NCC Group. “Striking Back at Retired Cobalt Strike: A look at a legacy vulnerability.” June 15, 2020. 57 virustotal.com. "52.157.171.98." 58 Cobalt Strike User Guide. "External C2." 59 VMware Carbon Black. “Knock, knock, Neo. Active C2 Discovery Using Protocol Emulation.” Takahiro Haruyama, 60 Fox IT. "Identifying Cobalt Strike team servers in the wild." Feb. 26, 2019. 61 Medium. “Identifying Cobalt Strike team servers in the wild by using ZoomEye (Part 2)." heige, KnownSec 404 Team. April 10, 2020. 62 Cobalt Strike. "Cobalt Strike Team Server Population Study." Raphael Mudge. Feb. 19, 2019. 63 Cobalt Strike User Guide. “Malleable Command and Control.” 64 Github. "Salesforce / jarm." 65 Cobalt Strike User Guide. "License Authorization Files." 66 Cobalt Strike. “Cobalt Strike Trial’s Evil Bit.” Raphael Mudge. Oct. 14, 2015. 67 MITRE ATT&CK. “Proxy: Domain Fronting.”. 68 Cobalt Strike. “High-reputation Redirectors and Domain Fronting.” Raphael Mudge.Feb. 6, 2017. 69 Microsoft. "Securing our approach to domain fronting within Azure." Eric Doerr. March 26, 2021. 70 NVISO Labs. “Cobalt Strike: Using Known Private Keys to Decrypt Traffic – Part 1." Didier Stevens. Oct. 21, 2021. 71 Cobalt Strike User Guide. “License Authorization Files.” 72 Group IB. “Big airline heist.” Nikita Rostovcev. Oct. 6, 2021. 73 LAC Watch. “Targeted attack by "Cobalt Strike loader" that abuses Microsoft's digital signature ~ Attacker group APT41." Yoshihiro Ishikawa. May 21, 2021. 74 Github. "Ne0nd0g / merlin." 75 Juniper Networks. “Linux Servers Hijacked to Implant SSH Backdoor.” Asher Langton. April 26, 2021. 76 Security Boulevard. "Detect C2 ‘RedXOR’ with state-based functionality.” Ben Reardon. April 20, 2021. 77 Intezer. “ACBackdoor: Analysis of a New Multiplatform Backdoor.” Ignacio Sanmillan. Nov. 18, 2019. 78 JPCERT CC. “ELF_PLEAD – Linux MalwareUsed by BlackTech.” Nov. 16, 2020. This report may contain hyperlinks to non-VMware websites that are created and maintained by third parties who are solely responsible for the content on such websites. Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries. |For ber ello kin Ars an A ypt Cam on en k a|ces 22, Bo g M en cti om pa men tati t a|Q 20 tne al al: ve inin ign ts. on leg|NA 21. t ta war A L Cry g Th ” G of C acy|P N rge e T ook pto wor at's al S ob vu|AS tin arg int jac k.” O ing alt lne|De g W etin o a kin Fer per er. Str rab|vic or g K Te g C na ate Ap ike. ility|es." dPr ub am am ndo d fo ril 3 " A .” J|Se ess ern TN pai Do r T , 2 vig un|rgi po ete T Se gn. mi wo 020 ayil e 15|u G ds. s." rv " Ju ngu Yea . Me , 2|atla " St Jay er.” ly ez rs. ch 020|n. efa Ch Tar 14, . Ja " N ting .|Jul no en a G 202 n. ath er,|y 10 Chi , Av ou 1. 9, 2 ani Ry|, 2 eri iv ld. 02 el Q an|019 ci. Sas Oct 0. uis Rob|. Aug son . 6 t. F ins|ust , A , 20 eb on|26 riel 21, . 17 , Jo|, 2 Ze , 20 aki|021 liva 21. m|. nsk Ken|y. ne|Feb dy.|. 3, Sep|t.|Col29|Col30|Col31|Col32|Col33|Col34|Col35| |---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---| ----- -----