Learn more about the Cyber Threat Alliance. Indicators of Compromise IoC Note bef87e4d9fcaed0d8b53bce84ff5c5a70a8a30542100ca6d7822cbc8b76fef13 svhost.exe (Ransomware Binary) 853909af98031c125a351dad804317c323599233e9b14b79ae03f9de572b014e Splashtop 24123421dd5b78b79abca07bf2dac683e574bf9463046a1d6f84d1177c55f5e5 Netscan 4724EE7274C31C8D418904EE7E600D92680A54FECDAC28606B1D73A28ECB0B1E Netscan 9c8a4159166062333f2f74dd9d3489708c35b824986b73697d5c34869b2f7853 Netscan e22008893c91cf5bfe9f0f41e5c9cdafae178c0558728e9dfabfc11c34769936 Netscan 8d069455c913b1b2047026ef290a664cef2a2e14cbf1c40dce6248bd31ab0067 Netscan 544a4621cba59f3cc2aeb3fe34c2ee4522593377232cd9f78addfe537e988ddc start.bat a15c7b264121a7c202c74184365ca13b561fb303fb8699299039a59ab376adc6 turnoff.bat b7fba3abee8fd3bdac2d05c47ab75fdaa0796722451bed974fb72e442ab4fefd newuser.bat e5cf252041045b037b9a358f5412ae004423ad23eac17f3b03ebef7c8147a3bb Mimikatz 5603d4035201a9e6d0e130c561bdb91f44d8f21192c8e2842def4649333757ab Mimikatz 69f245dc5e505d2876e2f2eec87fa565c707e7c391845fa8989c14acabc2d3f6 Mimikatz phandaledr@onionmail[.]org Ransom note contact email farusbig@tutanota[.]com Ransom note contact email how_to_decrypt.hta Ransom note name 94979b61bba5685d038b4d66dd5e4e0ced1bba4c41ac253104a210dd517581b8 DC2.exe 9c8a4159166062333f2f74dd9d3489708c35b824986b73697d5c34869b2f7853 DC4.exe c5d09435d428695ce41526b390c17557973ee9e7e1cf6ca451e5c0ae443470ca DC6.exe 3x55o3u2b7cjs54eifja5m3ottxntlubhjzt6k6htp5nrocjmsxxh7ad[.]onion Trigona TOR negotiation portal 45.227.253[.]99 IP address associated with Trigona activity 45.227.253[.]106 IP address currently hosting Trigona leak site 45.227.253[.]98 IP address associated with Trigona activity 45.227.253[.]107 IP address associated with Trigona activity Additional Resources Product Protection Guide Product/Service Course of Action Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement


The below courses of action mitigate the following techniques: Command and Scripting Interpreter [T1059], Create Account

BeeWare of Trigona An Emerging Ransomware Strain


[T1136], Account Manipulation [T1098], Local Account [T1136.001], File Deletion


[T1070.004], Modify Registry


[T1112], Disable or Modify Tools [T1562.001], Disable or Modify System Firewall


[T1562.004], Deobfuscate/Decode Files or Information


[T1140], Match Legitimate Name or Location


[T1036.005], Disable Windows Event Logging


[T1562.002], Obfuscated Files or Information [T1027], Clear Windows Event Logs


[T1070.001], Masquerade Task or Service [T1036.004], Credentials from Password Stores


[T1555], OS Credential Dumping [T1003], LSASS Memory [T1003.001], System Network Configuration Discovery


System Information Discovery


[T1082], Network Service Discovery [T1046], Permission Groups Discovery


[T1021.001], Lateral Tool Transfer [T1570], Software Deployment Tools


[T1072], Registry Run Keys / Startup Folder [T1547.001], Accessibility Features


[T1546.008], Bypass User Account Control


[T1548.002] Next-Generation Firewalls Ensure that the User-ID Agent has minimal permissions if User-ID is enabled Ensure that security policies restrict User-ID Agent traffic from crossing into untrusted zones Ensure that the User-ID service account does not have interactive logon rights Ensure that 'Include/Exclude Networks' is used if User-ID is enabled Ensure remote access capabilities for the User-ID service account are forbidden.


Ensure that User-ID is only enabled for internal trusted interfaces Define at least one 'Include Network'.


Ensure that all zones have Zone Protection Profiles with all Reconnaissance Protection settings enabled, tuned, and set to appropriate actions Ensure 'Service setting of ANY' in a security policy allowing traffic does not exist Ensure 'Security Policy' denying any/all traffic to/from IP addresses on Trusted Threat Intelligence Sources Exists Ensure application security policies exist when allowing traffic from an untrusted zone to a more trusted zone Cortex XSOAR Deploy XSOAR Playbook - Access Investigation Playbook Deploy XSOAR Playbook - Block Account Generic Deploy XSOAR Playbook - Impossible Traveler Deploy XSOAR Playbook - Port Scan Deploy XSOAR Playbook Cortex XDR - Isolate Endpoint Cortex XDR Prevent Configure Behavioral Threat Protection under the Malware Security Profile Enable Anti-Exploit Protection Configure Restrictions Security Profile Enable Anti-Malware Protection Configure Host Firewall Profile Threat Prevention Ensure that antivirus profiles are set to block on all decoders except 'imap' and 'pop3' Ensure an anti-spyware profile is configured to block on all spyware severity levels, categories, and threats Ensure a secure antivirus profile is applied to all relevant security policies Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement


Ensure that all zones have Zone Protection Profiles with all Reconnaissance Protection settings enabled, tuned, and set to appropriate actions Ensure 'Service setting of ANY' in a security policy allowing traffic does not exist Ensure 'Security Policy' denying any/all traffic to/from IP addresses on Trusted Threat Intelligence Sources Exists Ensure application security policies exist when allowing traffic from an untrusted zone to a more trusted zone Cortex XSOAR Deploy XSOAR Playbook - Access Investigation Playbook Deploy XSOAR Playbook - Block Account Generic Deploy XSOAR Playbook - Impossible Traveler Deploy XSOAR Playbook - Port Scan Deploy XSOAR Playbook Cortex XDR - Isolate Endpoint Cortex XDR Prevent Configure Behavioral Threat Protection under the Malware Security Profile Enable Anti-Exploit Protection Configure Restrictions Security Profile Enable Anti-Malware Protection Configure Host Firewall Profile Threat Prevention Ensure that antivirus profiles are set to block on all decoders except 'imap' and 'pop3' Ensure an anti-spyware profile is configured to block on all spyware severity levels, categories, and threats Ensure a secure antivirus profile is applied to all relevant security policies Persistence, Privilege Escalation, Defense Evasion


[T1070.001], Masquerade Task or Service [T1036.004], Registry Run Keys / Startup Folder [T1547.001], Accessibility Features


Cortex XSOAR Deploy XSOAR Playbook - Access Investigation Playbook Deploy XSOAR Playbook - Block Account Generic Deploy XSOAR Playbook - Impossible Traveler Cortex XDR Prevent Configure Behavioral Threat Protection under the Malware Security Profile Enable Anti-Exploit Protection Configure Restrictions Security Profile Enable Anti-Malware Protection Persistence, Privilege Escalation, Defense Evasion


The below courses of action mitigate the following techniques: File Deletion [T1070.004], Modify Registry


[T1548.002] Cortex XDR Prevent Configure Behavioral Threat Protection under the Malware Security Profile Enable Anti-Exploit Protection Configure Restrictions Security Profile Enable Anti-Malware Protection Privilege Escalation, Defense Evasion


[T1070.001], Masquerade Task or Service [T1036.004], Bypass User Account Control


[T1548.002] Cortex XDR Prevent Configure Behavioral Threat Protection under the Malware Security Profile Enable Anti-Exploit Protection Configure Restrictions Security Profile Enable Anti-Malware Protection Defense Evasion


[T1070.001], Masquerade Task or Service [T1036.004] Cortex XDR Prevent Configure Behavioral Threat Protection under the Malware Security Profile Enable Anti-Exploit Protection Configure Restrictions Security Profile Enable Anti-Malware Protection Credential Access The below courses of action mitigate the following techniques: Credentials from Password Stores


[T1555], OS Credential Dumping [T1003], LSASS Memory [T1003.001] Cortex XDR Prevent Enable Anti-Exploit Protection Enable Anti-Malware Protection Discovery


[T1082], Network Service Discovery [T1046], Permission Groups Discovery [T1069] Next-Generation Firewalls Ensure that all zones have Zone Protection Profiles with all Reconnaissance Protection settings enabled, tuned, and set to appropriate actions Ensure 'Service setting of ANY' in a security policy allowing traffic does not exist Ensure 'Security Policy' denying any/all traffic to/from IP addresses on Trusted Threat Intelligence Sources Exists Ensure application security policies exist when allowing traffic from an untrusted zone to a more trusted zone Cortex XSOAR Deploy XSOAR Playbook - Port Scan Lateral Movement


[T1021.001], Lateral Tool Transfer [T1570] Next-Generation Firewalls Ensure 'Service setting of ANY' in a security policy allowing traffic does not exist Ensure remote access capabilities for the User-ID service account are forbidden.


Ensure that the User-ID Agent has minimal permissions if User-ID is enabled Ensure that User-ID is only enabled for internal trusted interfaces Ensure application security policies exist when allowing traffic from an untrusted zone to a more trusted zone Ensure that the User-ID service account does not have interactive logon rights Ensure that all zones have Zone Protection Profiles with all Reconnaissance Protection settings enabled, tuned, and set to appropriate actions Ensure that 'Include/Exclude Networks' is used if User-ID is enabled Ensure that security policies restrict User-ID Agent traffic from crossing into untrusted zones Ensure 'Security Policy' denying any/all traffic to/from IP addresses on Trusted Threat Intelligence Sources Exists Cortex XDR Prevent Configure Host Firewall Profile Cortex XSOAR Deploy XSOAR Playbook - Access Investigation Playbook Deploy XSOAR Playbook - Block Account Generic Threat Prevention Ensure that antivirus profiles are set to block on all decoders except 'imap' and 'pop3' Ensure an anti-spyware profile is configured to block on all spyware severity levels, categories, and threats Ensure a secure antivirus profile is applied to all relevant security policies Command and Control


The below courses of action mitigate the following techniques: Remote Access Software [T1219],


Ingress Tool Transfer [T1105] Next-Generation Firewalls Ensure that the Certificate used for Decryption is Trusted Ensure application security policies exist when allowing traffic from an untrusted zone to a more trusted zone Ensure 'Security Policy' denying any/all traffic to/from IP addresses on Trusted Threat Intelligence Sources Exists Ensure 'SSL Forward Proxy Policy' for traffic destined to the Internet is configured Ensure 'SSL Inbound Inspection' is required for all untrusted traffic destined for servers using SSL or TLS Ensure 'Service setting of ANY' in a security policy allowing traffic does not exist Setup File Blocking Threat Prevention Ensure DNS sinkholing is configured on all anti-spyware profiles in use Ensure passive DNS monitoring is set to enabled on all anti-spyware profiles in use Ensure a secure anti-spyware profile is applied to all security policies permitting traffic to the Internet Ensure that antivirus profiles are set to block on all decoders except 'imap' and 'pop3' Ensure an anti-spyware profile is configured to block on all spyware severity levels, categories, and threats Ensure a secure antivirus profile is applied to all relevant security policies URL Filtering Ensure secure URL filtering is enabled for all security policies allowing traffic to the Internet Ensure all HTTP Header Logging options are enabled Ensure that PAN-DB URL Filtering is used Ensure that URL Filtering uses the action of “block” or “override” on the URL categories


Ensure that access to every URL is logged Cortex XSOAR Deploy XSOAR Playbook - PAN-OS Query Logs for Indicators Deploy XSOAR Playbook - Hunting C&C Communication Playbook (Deprecated) Deploy XSOAR Playbook - Block URL Deploy XSOAR Playbook - Block IP Cortex XDR Prevent XDR BIOCs / ABIOCs Impact


The below courses of action mitigate the following techniques: Data Encrypted for Impact [T1486], Service Stop [T1489],


Product Protection Guide.


This post is also available in: 日本語 (Japanese)Author's Note New evidence has emerged that suggests the group WatchDog was behind a cryptojacking campaign that we attributed to TeamTNT in a blog published on June 8, 2021.

Updated New Evidence Emerges to Suggest WatchDog Was Behind Crypto Campaign


This updated information changed our view on the evidence initially gathered by Unit 42 researchers.


Specifically, the domain oracle.zzhreceive[.]top was originally linked to TeamTNT operations due to the usage of the term zzhreceive, which has been witnessed within several TeamTNT operations.


Given recent developments and the growing analytic visibility within the cloud research community, this domain has now been attributed to the cryptojacking operations associated with the group WatchDog.


The following is an update of our original blog, more accurately aligned to the current intelligence community information regarding WatchDog’s mimicry of TeamTNT operations.


Executive Summary The copying and incorporation of cryptomining operational codebase or script functions have become a central behavioral indicator of cryptojacking groups and their operations.


Unit 42 researchers have identified tactics, techniques and procedures (TTPs) used by the TeamTNT cryptojacking group being used by the WatchDog cryptojacking group.


The new scripts from WatchDog are overtly copying TeamTNT infrastructure naming conventions and using a known WatchDog C2 hosting system, 199.199.226[.]117.


With the identification of these new WatchDog scripts, Unit 42 researchers found that techniques that have been synonymous with the TeamTNT group have gone missing.


For instance, the new scripts do not: Researchers have also observed that the new WatchDog scripts do not use the exploit-laden GoLang binaries traditionally associated with WatchDog.


While WatchDog is believed to be the author of these new scripts, several of the scripts were found within TeamTNT-owned public malware repositories.


It appears that WatchDog may be attempting to expand their cryptojacking operations, while simultaneously masking their operations to appear more like the known cryptojacking operations performed by TeamTNT.


The stealing, hijacking or incorporation of cryptojacking TTPs within other cryptojacking operations has become a common trend within cryptojacking groups.


Most notably, TeamTNT was reported to have copied the code used to detect and remove Alibaba Cloud Security from compromised instances from the Kinsing group.


Also, cryptojacking groups such as “Rocke” began as a forked GitHub repository from the cryptojacking operation created by “The 8220 Mining Group.”


This operation shares up to 30% of its cryptomining code base with tools developed by the group “Pacha.”


Pacha and Rocke were subsequently involved in a documented crypto war, which has lasted nearly two years.


While little research has been written on recent Pacha operations, Rocke is still developing new malware.


Palo Alto Networks customers running Prisma Cloud are protected from the threats presented in this report through the Runtime Protection feature, Cryptominer Detection feature and the Prisma Cloud Compute Kubernetes Compliance Protection, which alerts on an insufficient Kubernetes configuration and provides secure alternatives.


Additionally, Palo Alto Networks VM-Series and CN-Series products offer cloud protections that can prevent network connections from cloud instances toward known malicious IP addresses and URLs.


New WatchDog Malware There are two samples that show the evolution of WatchDog techniques to mimic TeamTNT operations, 36ca9f84864ad022c255b7d91e75997f035716e4df5dc1c90ee2651f092f5d79 and 49366ae4766492d94136ca1f715a37554aa6243686c66bf3c6fbb9da9cb2793d.


These samples, first witnessed on Dec. 5 and 11, 2020, respectively, show the direct replacement of the known WatchDog C2 infrastructure with new C2 infrastructure.


As shown in Figure 1, the original WatchDog infrastructure, in the dark blue rectangle, has been commented out of the bash script functionality and replaced with the new infrastructure seen in the light blue rectangle.


WatchDog infrastructure replacement.


The new script also makes use of the exact URL address directory tree pattern that is present within the known WatchDog operations, with the directories b2f628 (red) and b2f628fff19fda999999999 (orange), as shown in Figure 2. Figure 2. URL directory pattern.


These two samples contain a hardcoded Monero (XMR) wallet address and an associated mining pool, as shown in Figure 3. Figure 3.


Monero wallet and associated mining pool.


Mining Pools If these changes are indeed new TeamTNT behaviors, which is highly unlikely, it would represent the first time the TeamTNT cryptojacking operations have used a mining pool outside their traditional Monero mining pool, MoneroOcean[.]stream.


This cryptojacking operation introduces two new mining pools never before known to be used by TeamTNT actors, but have been witnessed within WatchDog operations.


These mining pools are nanopool[.]org, shown in Figure 4, and f2pool[.]com, shown in Figure 5.


The new mining pools are both instructed to use the Monero wallet address, 43Xbgtym2GZWBk87XiYbCpTKGPBTxYZZWi44SWrkqqvzPZV6Pfmjv3UHR6FDwvPgePJyv9N5PepeajfmKp1X71EW7jx4Tpz.


Nanopool mining operation.


F2pool mining operation.


Mining Pool Worker Information Of note are the names of the mining pool workers associated with this Monero wallet address within the mining pools.


According to nanopool[.]org records related to this Monero wallet address, there are a total of 20 unique workers, as shown in Figure 6. Figure 6.


Nanopool mining operation workers.


The following table, Table 1, lists 19 of the currently known malicious samples which contain the Monero wallet address, the Nanopool mining pool and the name of one of the workers listed within Figure 6. SHA256 Worker 0414946ab4bced2c1c41f4b8a75be672b34bbdee6f29e0a0bf7946b93f7044b1 3910 34b547b567309618422d7075322ddf5b9e0b3a4fb652f3845d12fd649f23923e 3910 62957aa4421c044927269e9bf3300515cf01225fd4c3c3811f8ebfac7a9f8585 3910 f235c021baa6c8801e724d45003b1b1541eea5483810abc9c3eb4df6bf05afbf 3910 2bc6c21d35ed63b135b4723444a9ac532e4cb6aaa2bbd63c557136edb4e4756f crondk1 cbf54a9e5771fcb3760e4e282f003a879164e76b9df9fed0fe4e4e8aaaef11ae crondk1 428633aee75f7c69a7c0612e591d5fcecbcf13619d6c05b86c8303a248c7c8d7 dk2 7b6f7c48256a8df2041e8726c3490ccb6987e1a76fee947e148ea68eee036889 dk2 10fb8d16f7d168340be28c6d0ba94e10c15370c8747d97bc0e5fad4b4466cf09 dream 3b280a4017ef2c2aef4b3ed8bb47516b816166998462899935afb39b533890ad dream 8adc8be4b7fa2f536f4479fa770bf4024b26b6838f5e798c702e4a7a9c1a48c6 dream af611a41c55e9afcfaced8b067a470caa70825fce0a44167f44a8d3880ae6674 dream e1d7014b84618cd7fbf94439c78fe7d67f351cbc5536885fa3d94ea15325d83b dream eca42c42f0909cf4e6df6bf8de35ab93ef6a3dd10d0d5e556721ec1871a9990c dream ae6822d1fd097e8c52cea3731cd49f50600b7da83e9f0ea6dbc689685f907739 dream3 3b280a4017ef2c2aef4b3ed8bb47516b816166998462899935afb39b533890ad dream5 ae3e4a1c8a2b661265e6c8c756e3ba472dc7177cae79fe1861ab0c2d1af5167a dream6 8adc8be4b7fa2f536f4479fa770bf4024b26b6838f5e798c702e4a7a9c1a48c6 dream8 33da23085fb6fd7aad89e0c55b7ccbc2ee50fec4e8e31030e4b2a4ef034ac5f6 pokemon2 Table 1.


Malware samples with hardcoded Nanopool mining operation workers.


There were also 13 malicious samples containing the 43Xb Monero wallet address, but these samples are designed to use the f2pool[.]com mining pool instead of the nanopool[.]org Monero mining pool (see Table 2).


SHA256 Worker WatchDog Wallet f235c021baa6c8801e724d45003b1b1541eea5483810abc9c3eb4df6bf05afbf 3910 3d8a6f5d8162e8eb78e7b95384ec6418f65b904dffa8fd983a6a19a5645ad707 clean c141eaeab461a2481124a73ee2d254301573d8722dbf3221f5fc54d7770e67a2 clean Yes 64072e7c56895f59124c4e26e0dd65a4de0bd8280c83372c18f9835978cda0e9 clean 30f0207b74d6d2d17cd8f4dc9f9131bd8763702f19c87ce74ea13a634f52c995 clean Yes 7a8c91f4228be4d36e1087acc9bb046373ddfde506fe4645ad1b0967c08bfa8b clean Yes 7848fc64c9977796dcc0ee67c293f006d715d3b3e257a3c0f4654cefab637c45 clean Yes 3e6cf5ae8ce6ff7305da4e218a20ec7f57933235ec07d7ff6e6a18c7c844ff29 clean Yes 8d9bdcae4a4559e52b3d03209a1ef880e948d9f3969f7779119d9322c5f7cf7c clean Yes ab73aedbee66081cd047b19a4bb036f85791a9ae9abc90545c5d8756bbc2a428 clean Yes eca42c42f0909cf4e6df6bf8de35ab93ef6a3dd10d0d5e556721ec1871a9990c dream e47802d7f44fc9e594b89ef33298367d21695d5ec1ae5e6c526b9f3124c555ca Undefined cf890e288f4fb7a2cfb0aa7e91229cc51c224e767c6ca69bbbb9d06e999ede64 Undefined Table 2.


Malware samples with hardcoded f2pool mining pool operation workers.


Seven samples within the previous table contain instructions to find and remove any processes using the WatchDog-identified 43XB Monero wallet address, as shown in Figure 7. Figure 7.


Identification and killing of processes using the WatchDog Monero address.


The scripts will then rebuild mining operations and begin using two known WatchDog Monero wallet addresses, 82etS8QzVhqdiL6LMbb85BdEC3KgJeRGT3X1F3DQBnJa2tzgBJ54bn4aNDjuWDtpygBsRqcfGRK4gbbw3xUy3oJv7TwpUG4 and 87q6aU1M9xmQ5p3wh8Jzst5mcFfDzKEuuDjV6u7Q7UDnAXJR7FLeQH2UYFzhQatde2WHuZ9LbxRsf3PGA8gpnGXL3G7iWMv.


These two Monero wallets are just two of the three known Monero wallets that are associated with the WatchDog cryptojacking group.


Of note, the IP address listed within Figure 8, 139.99.102[.]72, resolves to the previously mentioned xmr-asia1.nanopool[.]org mining pool.


WatchDog Monero wallet addresses.


Linking WatchDog Infrastructure to TeamTNT The URL addresses and Monero wallet address, 87A5fSCR98nFSR9NCRxt6UFytca3hJXaRdDgf9NxhWTjT3q3AA8HECyZ1FdF93D5LPXsSqS8dKNsxCxafrbuVeZfMW3V7ib, specifically called out within the sample 36bf7b2ab7968880ccc696927c03167b6056e73043fd97a33d2468383a5bafce (see Figure 9), are known WatchDog indicators.


However, the sample also includes the email address hilde@teamtnt[.]red, which is a known TeamTNT email address. Figure 9.


Known WatchDog indicators of compromise (IoCs), as well as the TeamTNT email address.


Now to the malware sample, 8adc8be4b7fa2f536f4479fa770bf4024b26b6838f5e798c702e4a7a9c1a48c6, which contains the new WatchDog Monero wallet, as shown in Figure 10.


The same MOxmrigMOD URL address as the known TeamTNT IoC shown within Figure 9 is present, but in this sample we also see additional URL addresses that have very strong ties to WatchDog infrastructure, specifically those involving the domain name oracle.zzhreceive[.]top.


New IoCs analyzed in surrounding text.


With the presence of the C2 infrastructure from these new scripts, Figure 9 and Figure 10, both of which use the WatchDog directory, b2f628, there is a clear link to the TeamTNT infrastructure.


The domain oracle.zzhreceive[.]top resolves to the IP address 199.19.226[.]117, which is also the resolution IP address for the known TeamTNT subdomain zzhrecieve.anondns[.]net.


The usage of the anondns[.]net domain has been linked to several TeamTNT campaigns across multiple reports including, irc.anondns[.]net, ircbd.anondns[.]net, sampan.anondns[.]net and teamtntisback.anondns[.]net.


Additionally, the 199.19.226[.]117 system has also been linked to WatchDog operations through the toolkit file 1.0.4.tar.gz, 51de345f677f46595fc3bd747bfb61bc9ff130adcbec48f3401f8057c8702af9, which was hosted on hxxp://global.bitmex[.]com[.]de/cf67355a3333e6/1.0.4.tar.gz and contains C code for the masscan utility, which is the same toolkit used in the TeamTNT operations.


The bitmex[.]com[.]de URL had previously been linked to the WatchDog cryptojacking group.


TeamTNT Malware Repository


The malware repository 85.214.149[.]236:443/sugarcrm/themes/default/images/ contains known TeamTNT malware that includes the same files as the known TeamTNT repository hxxp://dockerupdate.anondns[.]net:443/sugarcrm/themes/default/images/, which is linked to TeamTNT via the malware sample 1aaf7bc48ff75e870db4fe6ec0b3ed9d99876d7e2fb3d5c4613cca92bbb95e1b, as shown in Figure 11.


Known TeamTNT malware repository.


Of note, some the of malware samples included in this repository were the Kubernetes and Docker-focused malware, ‘kube.jpg’ and ‘tshd’, presented in Unit 42's Black-T blog, but these appear to no longer be used in the new scripts discussed within this blog.


See the appendix for a full listing of the known TeamTNT malware metadata collected from the malware repository.


The malware sample 0414946ab4bced2c1c41f4b8a75be672b34bbdee6f29e0a0bf7946b93f7044b1 is of note in this context as it contains the hardcoded IP address, 199.19.226[.]117, as well as the hardcoded Monero wallet address associated with the nanopool and f2pool mining pools, and the mining workers previously discussed (Figures 12 and 13).


As the previous section mentioned, the IP address 199.19.226[.]117 also resolves to the known TeamTNT domain zzhrecieve.anondns[.]net. Figure 12.


WatchDog directory using TeamTNT infrastructure.


WatchDog Monero wallet address within TeamTNT infrastructure.


Finally, another TeamTNT malware repository was identified by Unit 42 researchers, as shown in Figure 14.


The larger Chimaera repository contains known TeamTNT cryptojacking scripts and binary files.


Within the spread/redis directory, the file b.sh, 3b14c84525f2e56fe3ae7dec09163a4a9c03f11e6a8d65b021c792ad13ed2701, was found, which directly links TeamTNT to the cryptojacking operations expressed in this report.


TeamTnT repository containing the b.sh script.


The b.sh script contains the 43xb TeamTNT and WatchDog Monero wallet address and points to the 199.19.226[.]117 TeamTNT and WatchDog IP addresses (Figure 15).


It also contains a hardcoded link to a known TeamTNT cloud enumeration script hosted on the known TeamTNT domain borg[.]wtf, see Figure 16. Figure 15.


TeamTNT and WatchDog XMR wallet and IP address.


Known TeamTnT domain borg[.]wtf.


The borg[.]wtf domain was linked to TeamTNT via a previous Unit 42 report.


The correlations between TeamTNT and WatchDog are intrinsically connected with this b.sh script.


Conclusion Considering the above evidence, it appears that WatchDog operations have incorporated the TTPs of the TeamTNT cryptojacking group and have significantly increased their own cryptojacking operations.


The new WatchDog operation does not appear to use the advanced functionalities TeamTNT has used recently, namely cloud credential scraping as well as targeted Kubernetes- and Docker-focused lateral movement and exploit scripts.


It’s also noteworthy that the new operation does not incorporate the more advanced GoLang binaries traditionally associated with WatchDog, which are capable of exploiting Windows- or NIX-based operating systems.


It appears that WatchDog actors are attempting to expand their cryptojacking operations, while simultaneously masking their operations with those of the known cryptojacking operations performed by TeamTNT.


Unit 42 researchers will continue to monitor this cryptojacking event and provide updates as needed.


The following tips are highly recommended by Unit 42 researchers to assist in the protection of cloud infrastructure.


Monitor and block network traffic to known malicious endpoints.


Only deploy vetted container images within production environments.


Implement and use Infrastructure as Code (IaC) scanning platforms to prevent insecure cloud instances from being deployed into production environments.


Use cloud infrastructure configuration scanning tools that enable governance, risk management and compliance (GRC) to identify potentially threatening misconfigurations.


Use cloud endpoint agents to monitor and prevent the running of known malicious applications within cloud infrastructure.


Palo Alto Networks Prisma Cloud customers are protected from these threats through the Runtime Protection feature, Cryptominer Detection feature and the Prisma Cloud Compute Kubernetes Compliance Protection, which alerts on an insufficient Kubernetes configuration and provides secure alternatives.


Additionally, Palo Alto Networks VM-Series and CN-Series products offer cloud protections that can prevent network connections from cloud instances toward known malicious IP addresses and URLs. Indicators of Compromise IP Addresses 103.125.218[.]10747.253.42[.]213176.123.10[.]5739.100.33[.]20945.9.150[.]36106.15.74[.]11345.9.148[.]3513.245.9[.]14785.214.149[.]23645.9.148[.]37199.19.226[.]117 URL Addresses 85.214.149[.]236:443/sugarcrm/themes/default/images/ hxxp://dockerupdate.anondns[.]net:443/sugarcrm/themes/default/images/ Domains global.bitmex.com[.]degsearch.com[.]dede.gsearch.com[.]deoracle.zzhreceive[.]topzzhreceive.anondns[.]netprojectbluebeam.anondns[.]net Monero (XMR) Wallets 43Xbgtym2GZWBk87XiYbCpTKGPBTxYZZWi44SWrkqqvzPZV6Pfmjv3UHR6FDwvPgePJyv9N5PepeajfmKp1X71EW7jx4Tpz Monero (XMR) Mining Pools xmr-asia1.nanopool[.]org:14444xmr.f2pool[.]com:13531Xmr.pool.gntl.co[.]uk:10009xmr.bohemianpool[.]com Repository SHA256 Hashes SHA256 FileName a506c6cf25de202e6b2bf60fe0236911a6ff8aa33f12a78edad9165ab0851caf kube.jpg e15550481e89dbd154b875ce50cc5af4b49f9ff7b837d9ac5b5594e5d63966a3 bioset.jpg 252bf8c685289759b90c1de6f9db345c2cfe62e6f8aad9a7f44dfb3c8508487a tshd.jpg 139f393594aabb20543543bd7d3192422b886f58e04a910637b41f14d0cad375 default.jpg 4f115381c17ba1dedb25d35d922feda9a723e206d811ed437b75fd8116ef461b 21.jpg 4a5d3435cd4a835056b4940e1cea9a25b1619562525bd9953a120b556b305983


22.jpg feb0a0f5ffba9d7b7d6878a8890a6d67d3f8ef6106e4e88719a63c3351e46a06 mod.jpg 2c40b76408d59f906f60db97ea36503bfc59aed22a154f5d564d8449c300594f stock.jpg 9791ab0a00caf9de8df9eab1d8998d1b48bcc7c724b7d833cb1793cadc577e5f beta.jpg 72b1cbfbd87c6cd85b9dc1da48c852768003e7fb4f01d8f6904921474be199ad ms.jpg b5f6d6114e1ce863675df1bf2e4bfaeac243e22bb399e64b9a96c6d975330b28 mo2.jpg 88585888c4dd2450cc885fc8b75b555ea6f924c78581d5eeae5b54b4b6951ac5 b_armv7l ce5cd41711e74f11d8c01380194d9bb542da08733c81c317ec51089137330e0c blue.tmp.jpg 36bf7b2ab7968880ccc696927c03167b6056e73043fd97a33d2468383a5bafce mos.jpg 1aaf7bc48ff75e870db4fe6ec0b3ed9d99876d7e2fb3d5c4613cca92bbb95e1b nk.jpg 3ef459b97522a8e39953befa2e8c0e970bbbb0f7f9d3e1ff22b0f7759de04be1 b374k-master.zip c0ab7d1caabdd090b2399cd1193d2cc2334218d3f3f0d3164b61b6014fd308e9 mod.js 230e2a06df2cd7574ee15cb13714d77182f28d50f83a6ed58af39f1966177769 Carray.jpg b556d266b154c303bb90db005d7dd4267ed8d0e711e3fd32406c64b1fc977f9e local.jpg 78037e2d2e596bd450b99551535fa9c38c4e8346ab75eb424bf9e95316424fbe 01.jpg f3b53ebc7cb45c57854059be00ccde4c05cb1d66c4c5c55a93072b76f07a9c38 armv7l_xmrig.jpg ad1133cdcb486bab2368347b3ab35e83e5cd492c4bc6bfcb11a4b4c99d2c8014 xmrig-6.3.3-linux-static-x64.tar.gz bc02d0f9ec27f3c8d23c2f4647007e37a86fd404df0eef76c081fbb895f1be1b ktu.jpg 2a373d3e3e61999af09322b35356d26f95e183b1bb6222cae24d28b7b00ca01f flink.jpg bcfa215dec8fe15d4265c508c39c1ebafb7370acc95721e4e7d610b0459eb8dd jq.jpg b63efd9cca6a7379bc2a7e2b1ef721eedb0f3ac95afc14f2dd8db34f95688523 logs 79a060a0efcf4a1538c58e532b984dcd927fda17ca9fd10c2ff212f9d9d76be6 det.jpg b257a06a185f07e416f2b5ccc891fb799b82ce06bf1d4620d2439be65556c926 sok.js b485e6ccc9cfeb9c2034cebfeaf1bb3b3db0ac9996e5260fc1e95ce852b757c4 ssh.jpg Hashes Used in This Investigation 0414946ab4bced2c1c41f4b8a75be672b34bbdee6f29e0a0bf7946b93f7044b1 05963eaca329830c80a7fa2e9bea3b4ec2fe277f882f68be29befedb80d5738d 0910f78b68ccf1127a6a8f55d48b55c018149b4d5ab4a3fde56386a61c029ef4 10fb8d16f7d168340be28c6d0ba94e10c15370c8747d97bc0e5fad4b4466cf09


This blog post was authored by hasherezade NSIS (Nullsoft Scriptable Install System) is a framework dedicated to creating software installers.


It allows to bundle various elements of an application together (i.e. the main executable, used DLLs, configs), along with a script that controls where are they going to be extracted, and what their execution order is.


It is a free and powerful tool, making distribution of software easier.


Unfortunately, its qualities are known not only to legitimate developers but also to malware distributors.


For several years we have been observing malware distributed via NSIS-based crypters.


The outer layer made of a popular and legitimate tool makes for a perfect cover.


The flexibility of the installer allows to implement various ideas for obfuscating malicious elements.


We wrote about unpacking them in the past, i.e. here, and here.


With time their internal structure has evolved, so we decided to revisit them and describe the inside again using samples from some of the Formbook stealer campaigns.


Samples This analysis is based on the following samples: 8F80426CEC76E7C9573A9C58072399AF carrying a Formbook sample: 05dc8c8d912a58a5dde38859e741b2c098061CCF694005A78FCF0FBC8810D137carrying a Formbook sample: f34bd301f4f4d53e2d069b4842bca672 Inside Like every NSIS-based installer, this executable is an archive that can be unpacked with the help of 7zip.


The older versions of 7zip (i.e.15.05) were also able to extract the NSIS script:


[NSIS].nsi.


Unfortunately, in the newer releases script extraction is no longer supported.


Once we unpack the file, we can see several elements, as well as directories typical for NSIS:


The System.dll is a DLL typical for any NSIS installer, responsible for executing the commands from the script.


It is the first component of the archive to be loaded.


We can find it in each of the samples.


What is more interesting are the files in the main directory.


The first one, 1 KB in size, is a shellcode.


It starts from bytes: 0x55, 0x8B, 0xEC, 0x81, 0xEC Analogous shellcode can be found in the second sample from this campaign.


In the same directory there are two other files.


One of them is around 7 KB, and the next: much bigger.


Both of them are encrypted, and to find out what they contain we need to analyze the full chain of loading.


Looking inside the NSIS script we can see the performed actions that are very simple: Function .onInit InitPluginsDir SetOutPath


$INSTDIR File 5e9ikl8w3iif7ipp6 File 3ugs67ip868x5n File tjdorfrldbgdlq System::Alloc 1024 Pop $0 System::Call "kernel32::CreateFile(t'$INSTDIR\tjdorfrldbgdlq', i 0x80000000, i 0, p 0, i 3, i 0, i 0)i.r10" System::Call "kernel32::VirtualProtect(i r0, i 1024, i 0x40, p0)p.r1" System::Call "kernel32::ReadFile(i r10, i r0, i 1024, t., i 0)


i .r3


" System::Call ::$0() Call func_80


[...] The first file of the set (containing the shellcode) is read into the executable memory.


Then, the loaded module is just called.


Shellcode #1 – functionality If we load those shellcodes into IDA we can see their functionality very clearly, as they are not obfuscated.


Shellcode from sample #1: Shellcode from sample #2 Although the code is a bit different in both, they can be divided with the same steps and building blocks.


The name of the next file is loaded as a stack-based wide stringThe base of kernel32.dll is fetched from PEBA set of function from kernel32.dll is retrieved – each of them by the name’s checksums.


Functions are always the same – dedicated to reading the file from the disk: CreateFileW, GetTempPathW, lstrcatW, ReadFile, VirtualAlloc, GetTempPathW.The function GetTempPathW is used to retrieve the path to the %TEMP% directory, where all the components from the archive were automatically extracted at runtime of the NSIS fileThe name of the next file is concatenated to the the %TEMP% pathMemory is allocated for the file content, and the file is read into this bufferA custom decryption algorithm is being applied on the buffer (the algorithm is different for different samples).


The buffer turns out to be a next shellcodeFinally, the next shellcode is executed The name of the next file is loaded as a stack-based wide string The hashing function used for import resolving follows the same pattern in both cases, yet the constant used to initialize it (denoted as HASH_INIT) is different across the samples.


int __


stdcall


*name) { int next_chunk; int hash; for ( hash = HASH_INIT; ; hash = next_chunk + 33 * hash ) { next_chunk = *name++; if ( !next_chunk ) break; } return hash; } view raw nsis_calc_hash.cpp hosted with :red_heart: by GitHub The algorithm used for the buffer decryption differs across the samples.


The second shellcode revealed after the unpacking algorithm finished processing Shellcode #2 – functionality This shellcode is used for decrypting and loading the final payload (PE file) from the third of the encrypted files.


It is unpacked and ran by the previous layer.


In the analyzed cases, this element was around 7-8 KB.


This shellcode is similarly structured as the previous one.


It starts by preparation of the strings: stack-based strings are being pushed.


One of them is the name of the next file that is going to be loaded.


Also, the key that will be used for the decryption is prepared.


The next step is loading of the imported functions.


As before, they are resolved by their hashes.


Then the functions are used to load and decrypt the payload.


If loading the next stage has failed, the installer will restart itself.


The decryption function is custom, similar (but not identical) to RC4: void __stdcall decrypt_buf(BYTE *data, BYTE *key, unsigned int size) { BYTE key_stream[512]; int j; char next;


int i; int v6 = 0; int v4 = 0; for ( i = 0;


i < 256; ++i ) { key_stream[i + 256] = i; key_stream[i] = key[i % size]; } for ( i = 0; i < 256; ++i ) { v6 = (key_stream[i] + v6 + key_stream[i + 256]) % 256; next = key_stream[v6 + 256]; key_stream[v6 + 256] = key_stream[i + 256]; key_stream[i + 256] = next; } v6 = 0; for ( j = 0; j < DATA_SIZE; ++j ) { i = (i + 1) % 256; v6 = (v6 + key_stream[i + 256]) % 256; next = key_stream[v6 + 256]; key_stream[v6 + 256] = key_stream[i + 256]; key_stream[i + 256] = next; v4 = (key_stream[v6 + 256] + key_stream[i + 256]) % 256; data[j] ^=


key[j % size]; data[j] ^= key_stream[v4 + 256]; } } view raw nsis_decrypt.cpp hosted with :red_heart: by GitHub


This algorithm is common to both analyzed samples – yet the decryption key differs.


Loading PE After the PE is decrypted, the function for its loading is deployed.


The payload is implanted into a newly created suspended process (a new instance of the current executable) using one of the most popular techniques of PE injection: Process Hollowing (a.k.a. RunPE).


The content of the payload is mapped into the new process using low level APIs: NtCreateSection, NtMapViewOfSection.


Then, the Entry Point is redirected to the new executable via SetThreadContext, and finally the execution is resumed with NtResumeThread.


The authors used several common techniques to obfuscate this process.


As before, the used functions are loaded by their checksums.


The PE loading function makes a use of the following set: The low-level functions, directly related with performing the injection, are called via raw syscalls retrieved directly from NTDLL.


Also in this case, functions has been resolved by their hashes.


List of used functions (with corresponding hashes).


4b1a50d1 : NtCreateSection


e0ddd5cb : NtMapViewOfSection 20b0f111 : NtResumeThread 81af6d4e : NtUnmapViewOfSection be530033 : NtWriteVirtualMemory The code used to resolve the hashes is available here: hash_resolver.cpp.


Overview of the PE loader Manual syscalls calling


In order to make the injection stealthier, the loader uses a common technique of “stealing syscalls”, also known as “hell’s gate”.


This technique is based on the fact that some low-level DLLs, such as NTDLL, contain numbers of raw syscalls.


By extracting the syscalls, and executing them manually, the malware can use the API of the operating system, without a need of calling functions from the DLL.


That allows to bypass some monitoring in the situation if the system DLLs are hooked.


More in-depth analysis of this technique was described here.


Firstly, a fresh copy of NTDLL is loaded from the file on the disk, an manually mapped.


Then, a function defined by its hash is retrieved (using the same hashing algorithm that was used to retrieve imports from normally loaded DLLs): After the pointer to the beginning of the function is fetched, a small disassembling loop is used to find the familiar pattern: moving the ID of the syscall into EAX register.


The syscall ID is returned for further use.


Once the syscall number has been extracted, the malware intends to execute it from its own code.


However, a 32-bit application cannot make direct syscalls on 64-bit system, since it is not native.


In such cases, syscalls are usually made via Wow64 emulation layer.


In order to make them directly, the authors of the malware switch to the 64-bit mode first: using a technique called “Heaven’s Gate”.


The malware comes with two variants of the stub executing a syscall.


The decision for which of the versions should be applied is made based on the check if the process runs as Wow64 (emulated 32 bit on 64 bit Windows): If the process runs on a 32-bit system, the syscall can be made in a direct way, using SYSENTER:


If the system is 64-bit, the malware (that is 32-bit) switches into 64-bit mode via “Heaven’s Gate”.


Far return to the address prefixed with 0x33 segment – entering the 64-bit mode Once the execution mode is changed into 64 bit, the syscall is called, its results stored, and the application can switch back to 32-bit mode to continue normal execution.


The 64-bit code, executed after the mode is switched via Heaven’s Gate Evolution This crypter has been around for several years, and during this time it went through several phases of evolution.


In this part of the analysis we will compare it with the earlier version from February of this year, described in the following writeup.


In contrast to the current one, the version from February contained a malicious component in the form of a DLL.


We can also find a second, encrypted component, which carries the payload.


The extracted NSIS script contains a different sequence of commands: Function .onInit SetOutPath


$INSTDIR File $INSTDIR\o15bmldpqdxcin.dll File $INSTDIR\emvmcmzr.n System::Call $INSTDIR\o15bmldpqdxcin.dll::Gxkeoxkzs(w$\"$INSTDIR\emvmcmzr.n$\") DetailPrint label StrCpy $0 9 IntOp $0 $0 + 4 Goto $0 DetailPrint done FunctionEnd In this case, the standard NSIS component (System.dll) is used to call the function exported from the DLL, passing the path to the encrypted component as a parameter.


Looking inside the exported function we can find a significant similarity to the Shellcode #1 which was described in the former part of this writeup.


As before, we can see decryption of the next stage with the help of a custom algorithm.


This time, the next stage is contained in a buffer hardcoded in the DLL (rather than stored in a separate file).


It contains a very similar function dedicated to decrypting and loading the final payload.


Yet, we can see some minor differences.


First of all, the file name is passed dynamically rather than hardcoded.


Second, we can see a check against blacklisted processes.


Their names are hashed, and compared to the hardcoded list of hashes (i.e. 0x26090612 -> “avgui.exe”).


This type of checks are among common evasion techniques.


However, in this case, detection of a forbidden process only delays execution, and does not suspend it or terminate.


Possibly it is a bug in the implementation, and the if statement was intended to be a while loop instead.


Nevertheless, the authors decided to give up the check in the latest version.


Apart from those details, this stage is identical to the Shellcode #2 from the newer version.


Popular and persistent


This packer has been around for many years, and probably will stay with us for some years to come.


Its structure shows that it is created by experienced authors, using well known, yet not trivial techniques.


Its evolution is slow but steady.


Usage of a popular installation engine makes it easy to blend in with legitimate applications.


Its popularity and diversity of payloads suggests that it is not linked to one specific actor, but rather sold as an independent component on one of many underground forums.


Appendix Other materials about previous versions of NSIS-based crypters: https://yoroi.company/research/yes-cyber-adversaries-are-still-using-formbook-in-2021/https://www.welivesecurity.com/2021/01/12/operation-spalax-targeted-malware-attacks-colombia/https://news.sophos.com/en-us/2020/05/14/raticate/https://www.mcafee.com/blogs/other-blogs/mcafee-labs/ransomware-families-use-nsis-installers-to-avoid-detection-analysis/https://www.microsoft.com/security/blog/2017/03/15/ransomware-operators-are-hiding-malware-deeper-in-installer-packages/https://isc.sans.edu/forums/diary/Quick+analysis+of+malware+created+with+NSIS/23703/ The post Revisiting the NSIS-based crypter appeared first on Malwarebytes Labs.


This blog was jointly written with Alejandro Prada and Ofer Caspi.


Executive summary SeroXen is a new Remote Access Trojan (RAT) that showed up in late 2022 and is becoming more popular in 2023.


Advertised as a legitimate tool that gives access to your computers undetected, it is being sold for only $30 for a monthly license or $60 for a lifetime bundle, making it accessible.


Key takeaways: SeroXen is a fileless RAT, performing well at evading detections on static and dynamic analysis.


The malware combines several open-source projects to improve its capabilities.


It is a combination of Quasar RAT, r77-rootkit and the command line NirCmd.


Hundreds of samples have shown up since its creation, being most popular in the gaming community.


It is only a matter of time before it is used to target companies instead of individual users.


Analysis Quasar RAT is a legitimate open-source remote administration tool.


It is offered on github page to provide user support or employee monitoring.


It has been historically associated with malicious activity performed by threat actors, APT groups (like in this Mandiant report from 2017), or government attacks (in this report by Unit42 in 2017).


It was first released in July 2014 as “xRAT” and renamed to “Quasar” in August 2015.


Since then, there have been released updates to the code until v1.4.1 in March 2023, which is the most current version.


As an open-source RAT tool with updates 9 years after its creation, it is no surprise that it continues to be a common tool used by itself or combined with other payloads by threat actors up to this day.


In a review of the most recent samples, a new Quasar variant was observed by Alien Labs in the wild: SeroXen.


This new RAT is a modified branch of the open-source version, adding some modifications features to the original RAT.


They’re selling it for monthly or lifetime fee.


Figure 1 contains some of the features advertised on their website.


SeroXen features announced on its website.


This new RAT first showed up on a Twitter account, established in September 2022.


The person advertising the RAT appeared to be an English-speaking teenager.


The same Twitter handle published a review of the RAT on YouTube.


The video approached the review from an attacking/Red Team point of view, encouraging people to buy the tool because it is worth the money.


They were claiming to be a reseller of the tool.


In December 2022, a specific domain was registered to market/sell the tool, seroxen[.]com.


The RAT was distributed via a monthly license for $30 USD or a lifetime license of $60 USD.


It was around that time that the malware was first observed in the wild, appearing with 0 detections on VirusTotal.


After a few months, on the 1st of February, the YouTuber CyberSec Zaado published a video alerting the community about the capabilities of the RAT from a defensive perspective.


In late February, the RAT was advertised on social media platforms such as TikTok, Twitter, YouTube, and several cracking forums, including hackforums.


There were some conversations on gaming forums complaining about being infected by malware after downloading some video games.


The artifacts described by the users matched with SeroXen RAT.


The threat actor updated the domain name to seroxen[.]net by the end of March.


This domain name was registered on March 27th, 2023, after seroxen[.]com was decommissioned.


The threat actor used GoDaddy for registration and Cloudflare for hosting the website.


These domains are only used for selling and marketing purposes, and not for Command and Control (C&C) communications.


Figure 2: SeroXen website Based on the packed versions uploaded to VT, it appears that the RAT is being used for targeting video game users.


Several lure injector cheat files have been observed with names invoking popular videogames such as Fortnite, Valorant, Roblox or Warzone2.


The threat actor used Discord for the distribution of some of the samples. Figure 3.


SeroXen timeline.


One of the most relevant announced features is that it is a fully undetectable version.


This is currently true from a static analysis point of view, since the RAT is packaged into an obfuscated PowerShell batch file.


The file’s size typically ranges between 12-14 megabytes, as we can see in sample 8ace121fae472cc7ce896c91a3f1743d5ccc8a389bc3152578c4782171c69e87 uploaded to VT on May 21.


Due to its relatively large size, certain antivirus may choose not to analyze it, potentially bypassing detection.


This sample currently has 0 detections on VT, but some of the crowdsourced Sigma Rules do detect the activity as suspicious.


As the malware is fileless and executed only in memory after going through several decryptions and decompression routines, it is more difficult to detect by antiviruses.


In addition, its rootkit loads a fresh copy of ntdll.dll, which makes it harder to detect by Endpoint Detection & Response (EDR) solutions that hook into it to detect process injections.


Regarding the dynamic analysis, it is worth noting that some sandbox environments might fail to detect the RAT due to its utilization of several techniques to evade virtualization and sandbox detection mechanisms and string encryption subsequent payloads.


The RAT employs anti-debugging techniques by leveraging Windows Management Instrumentation (WMI) to identify the system’s manufacturer.


This enables it to identify virtualization environments such as VMware and abort the execution to delay and make the analysis harder.


The RAT also checks for the presence of debuggers and uses pings make the threads sleep.


Currently, most child processes and files dropped during the execution of the RAT have a low detection rate.


Execution analysis When the malicious payload is delivered to the victim, commonly through a phishing mail or a Discord channel – the victim often receives a ZIP file containing a benign file in plain sight, and the heavily obfuscated batch file is hidden and automatically executed when launched.


The bat file format is always very similar and looks like the contents of Figure 4, followed by base64 encoded text later in the file.


Obfuscated bat script.


During the bat execution, the script extracts two separate binaries from the base64 encoded text, AES decrypts, and GZIP decompresses it to produce two separate byte arrays.


These byte arrays are then used with .NET reflection to perform an in-memory load of the assembly from its bytes, locate the binary’s entry point, and perform an Invoke on both.


Throughout the decryption process, the attackers had the need to create a legitimate looking folder to drop an illicit version of the System Configuration Utility msconfig.exe that is required later.


For this purpose, the script creates the folder “C:Windows System32”, with a space after Windows and deletes it as soon as the utility is running.


If it wasn’t for this file temporarily dropped into disk, the RAT would be fully fileless.


The execution of one of the above-mentioned binaries leads to another obfuscated binary carrying an embedded resource.


This resource is hidden behind anti-sandboxing and debugger techniques, only to lead to more obfuscation and encryption techniques that lead to the final payload.


This payload has been built using the Github project Costura, which allows SeroXen to pack the code’s dependencies into the .NET assembly so it can run self-contained.


Payload embedded resources.


The extraction of the resources leads to the final payloads.


This is in the form of two .NET assemblies: CSStub2.InstallStager.exe, and CSStub2.UninstallStager.exe.


And a Win32 binary called CSStub2.$sxr-nircmd.exe, which corresponds to the unmodified command-line utility NirCmd.


The payload InstallStager.exe is a compilation of the open-source rootkit named r77-rootkit – a fileless ring 3 rootkit written in .NET.


This rootkit supports both x32 and x64 Windows processes and has the following features: Fileless persistence: The rootkit is stored as obfuscated data in the registry and is spawned with PowerShell via Task Scheduler to be injected into the winlogon.exe process.


Child process hooking.


Option to embed additional malware to be executed with the rootkit – in this case NirCmd and/or Quasar.


The added malware will be decompressed and decrypted before it is injected into other processes.


In memory process injection: the rootkit injects itself and additional malware(s) into all processes.


Injection is done from memory: no files are needed to be stored on disk.


Hooking: Hooks several functions from ntdll.dll to hide its presence.


Communicating via NamedPipe:


The rootkit can receive a command from any running process.


Antivirus / EDR evasion:


The rootkit uses several evasion techniques: AMSI bypass: PowerShell inline script patches “amsi.dll!AmsiScanBuffer” to always return “AMSI_RESULT_CLEAN”.


DLL unhooking: Removes EDR hooks by loading a fresh copy of “ntdll.dll” from disk to avoid process hollowing detection Hiding entities: Hiding all entities starts with a configurable prefix, which in SeroXen’s case its “$sxr”.


This prefix hardens the visualization of the attack on the system, but eases attribution of the malware family during the analysis.


The prefix is used to hide files, directories, NamedPipes, scheduled tasks, processes, registry keys/values, and services.


R77 technical documentation provides a guideline of where can the prefix be found: Config parameter Details Example HIDE_PREFIX The prefix for name-based hiding (e.g. processes, files, etc…).


L”$sxr” R77_SERVICE_NAME32 Name for the scheduled task that starts the r77 service for 32-bit processes.


HIDE_PREFIX L”svc32″ R77_SERVICE_NAME64 Name for the scheduled task that starts the r77 service for 64-bit processes.


HIDE_PREFIX L”svc64″ CHILD_PROCESS_PIPE_NAME32 Name for the named pipe that notifies the 32-bit r77 service about new child processes.


L”.pipe” HIDE_PREFIX L”childproc32″ CHILD_PROCESS_PIPE_NAME64 Name for the named pipe that notifies the 64-bit r77 service about new child processes.


L”.pipe” HIDE_PREFIX L”childproc64″ CONTROL_PIPE_NAME Name for the named pipe that receives commands from external processes.


L”.pipe” HIDE_PREFIX L”control” The two main components in this project are the InstallStager service and the Rootkit.


The InstallStager service is responsible for: Creating a registry key to store the malware code and writes it as encrypted data.


Creating a scheduled task to execute the malware using PowerShell.


PowerShell will decompress and decrypt the final payload (Service) that will be injected into the winlogon.exe process and executed via dllhost.exe using process hollowing techniques.


Starting payload after decryption using process hollowing.


Now the second and main stage of the Rootkit is ready to start.


The service kicks off the load of the rootkit’s DLL that is embedded as a resource and saves its configuration as a registry key.


(In SeroXen case it’s


[HKEY_LOCAL_MACHINESOFTWARE$sxrconfig]).


The service creates 3 listener threads: NewProcessListener: Enumerates all running processes and injects the rootkit when new processes are created.


ChildProcessListener: Injects the rootkit to a newly created process by another process and updates the callee via NamedPipe. Figure 7.


Child process injection.


ControlPipeListener: Creates a NamedPipe to receive commands from any process.


Supported commands are listed below: Command Details CONTROL_R77_UNINSTALL The control code that uninstalls r77.


The control code that temporarily pauses injection of new processes.


CONTROL_R77_RESUME_INJECTION The control code that resumes injection of new processes.


CONTROL_PROCESSES_INJECT The control code that injects r77 into a specific process, if it is not yet injected. CONTROL_PROCESSES_INJECT_ALL


The control code that injects r77 into all processes that are not yet injected.


CONTROL_PROCESSES_DETACH The control code detaches r77 from a specific process.


The control code detaches r77 from all processes.


The control code that executes a file using ShellExecute.


CONTROL_USER_RUNPE The control code that executes an executable using process hollowing.


CONTROL_SYSTEM_BSOD The control code that triggers a BSOD.


CONTROL_R77_TERMINATE_SERVICE The control code that terminates the r77 service.


The DLL rootkit carries out process injections, executes commands received by other processes, and keeps out of sight any sign of SeroXen being executed within the system.


System function hooking.


As a summary of the execution process: Figure 9.


SeroXen decryption flow.


Since Seroxen is based on QuasarRAT, the C&C server utilizes the same Common Name in their TLS certificate.


The functionalities offered by the threat actor for the C&C server closely mirror those found in the Quasar Github repository, including support for TCP network streams (both IPv4 and IPv6), efficient network serialization, compression using QuickLZ, and secure communication through TLS encryption. Figure 10.


Quasar Server Certificate.


Conclusion The SeroXen developer has found a formidable combination of free resources to develop a hard to detect in static and dynamic analysis RAT.


The use of an elaborated open-source RAT like Quasar, with almost a decade since its first appearance, makes an advantageous foundation for the RAT.


While the combination of NirCMD and r77-rootkit are logical additions to the mix, since they make the tool more elusive and harder to detect.


The Alien Labs team will continue to monitor the threat landscape for SeroXen samples and infrastructure.


Detection methods The following associated detection methods are in use by Alien Labs.


They can be used by readers to tune or deploy detections in their own environments or for aiding additional research.


SURICATA IDS SIGNATURES 2035595:


ET TROJAN Generic AsyncRAT Style SSL Cert 2027619:


ET TROJAN Observed Malicious SSL Cert (Quasar CnC) Associated indicators (IOCs)


A list of indicators is also available in the OTX Pulse.


Please note, the pulse may include other activities related but out of the scope of the report.


TYPE INDICATOR DESCRIPTION SHA256 8ace121fae472cc7ce896c91a3f1743d5ccc8a389bc3152578c4782171c69e87 Example malware hash Mapped to MITRE ATT&CK The findings of this report are mapped to the following MITRE ATT&CK Matrix techniques:


TA0002 : Execution T1053: Scheduled Task/Job T1053.005:


Scheduled Task T1059: Command and Scripting Interpreter T1059.003:


Windows Command Shell TA0003: Persistence T1547: Boot or Logon Autostart Execution T1547.001 Registry Run Keys / Startup Folder TA0004: Privilege Escalation T1548:


Abuse Elevation Control Mechanism T1548.002: Bypass User Account Control TA0005: Defense Evasion T1112: Modify Registry T1553:


Subvert Trust Controls T1553.002:


Code Signing T1564:


Hide Artifacts T1564.001:


Hidden Files and Directories T1564.003: Hidden Window TA0006: Credential Access T1552: Unsecured Credentials T1552.001:


Credentials In Files T1555: Credentials from Password Stores T1555.003: Credentials from Web Browsers TA0007:


Discovery T1016:


System Network Configuration Discovery T1033: System Owner/User Discovery T1082: System Information Discovery T1614: System Location Discovery TA0008: Lateral Movement T1021:


Remote Services T1021.001:


Remote Desktop Protocol TA009: Collection T1005:


Data from Local System T1056: Input Capture T1056.001: Keylogging T1125: Video Capture TA0011: Command and Control T1090: Proxy T1095: Non-Application Layer Protocol T1105:


Ingress Tool Transfer T1571: Non-Standard Port T1573: Encrypted Channel: T1573.001: Symmetric Cryptography References:


Seroxen webpage Seroxen features Quasar RAT NirCmd – Windows command line tool (nirsoft.net) R77-rootkit The post SeroXen RAT for sale appeared first on Cybersecurity Insiders.


During our continuous threat hunting efforts to find malware in open-source repositories, the ReversingLabs team encountered a novel attack that used compiled Python code to evade detection.

When byte code bites Who checks the contents of compiled Python files


It may be the first supply chain attack to take advantage of the fact that Python byte code (PYC) files can be directly executed, and it comes amid a spike in malicious submissions to the Python Package Index (PyPI).


If so, it poses yet another supply chain risk going forward, since this type of attack is likely to be missed by most security tools, which only scan Python source code (PY) files.


We reported the discovered package, named fshec2, to the PyPI security team on April 17, 2023, and it was removed from the PyPI repository the same day.


The PyPI security team has also recognized this type of attack as interesting and acknowledged that it had not been previously seen.


Here’s how my threat research team identified the fshec2 as a suspicious package and the novel method that the attackers employed as they attempted to avoid detection.


I’ll also tell you what our researchers found when investigating the command-and-control (C2) infrastructure used by the malware — and provide evidence of successful attacks.


Unusual behaviors ReversingLabs regularly scans open-source registers such as PyPi, npm, RubyGems, and GitHub looking for suspicious files.


As the team observed before, these often jump out at us from the millions of legitimate, nonmalicious files hosted on these platforms because they exhibit strange qualities or behaviors that, experience tells us, often signal malicious intent.


That was the case with fshec2.


The package initially caught our attention following a scan using the ReversingLabs Software Supply Chain Security platform, which extracted a suspicious combination of behaviors from an fshec2 compiled binary.


Those suspicious behaviors extracted from the decompiled file included the presence of URLs that reference the host by IP address, as well as the creation of a process and execution of a file.


A manual review of the fshec2 package followed.


It revealed that it contains only three files.


The code inside two of those Python source code files, _init_.py and main.py, appeared benign.


It was only upon inspection of a decompiled version of the third file, full.pyc, that more interesting behaviors came to light and the true nature of the package emerged.


Figure 1: Files containing package functionality Unmasking an unusual loader Threat actors are always trying to evade detection from security solutions.


Obfuscation is one of the most popular methods to achieve this.


For example, several of our previous research blogs have explored incidents in the npm landscape in which JavaScript obfuscation was used.


That includes the Material Tailwind and IconBurst campaigns, as well as the more recent campaign we identified distributing Havoc malware.


Historically, npm has been the unfortunate leader and PyPI an also-ran in the race to see which open-source platform attracts the most attention from malware authors.


In the last six months, however, ReversingLabs and others have observed a marked increase in the volume of malware published to PyPI.


In fact, in May, the creation of new user accounts and projects on PyPI were temporarily suspended for a few hours due to a high volume of malicious activity.


Along with the increase in malicious modules, my team has observed an increase in the use of various obfuscation techniques in malware published to the PyPI repository.


One of the most popular obfuscation techniques is execution of Base64-encoded malicious code, which was first observed in campaigns related to W4SP authors in November 2022.


Variations of that attack, in which malicious code is embedded in code but shifted past the edge of default screen borders (thereby hiding it from view), are still seen in the wild.


Today, however, attackers have more tools at their disposal.


For example, use of W4SP crew obfuscation tools such as Hyperion and Kramer is on the rise — likely a response to the improving detection capabilities of security companies monitoring PyPI and other public package repositories.


The fshec2 package uses a significantly different approach that doesn’t rely on obfuscation tools.


It instead places the malicious functionality into a single file containing compiled Python byte code.


How Python attacks (usually) work Before I get to the new obfuscation method my team discovered, here’s a look at how malicious attacks using Python typically work.


There are three types of Python files that may play a role in a malicious campaign: plaintext Python files, which have a /oy extension; compiled Python files, which have a .pyc extension; and Python files that have been compiled into native executables using tools such as py2exe and PyInstaller.


In most of the malicious campaigns that my team has observed leveraging PyPI packages, the executables are not present in the malicious package but are downloaded and run by the plaintext PY files from external infrastructure.


But fshec2 is different.


Here, we observed a compiled Python file (full.pyc) present inside the PyPI package that contained malicious functionality.


The entry point of the package was found in the __init__.py file, which imports a function from the other plaintext file, main.py, which contains Python source code responsible for loading of the Python compiled module located in one of the other files, full.pyc.


This innocent-seeming import of a function triggers a previously unseen loading technique inside the main.py file that avoids using the usual import directive, which is the simplest way to load a Python compiled module (and also something that is likely to get noticed.)


Instead, Importlib, the implementation of import in Python source code portable to any Python interpreter, is used to avoid detection by security tools.


(Some explanation: Importlib is typically used in cases where the imported library is dynamically modified upon import.


However, the library loaded by main.py was unchanged, meaning that the regular import function would have sufficed.


This tends to support the theory that Importlib is used to avoid detection.)


Figure 2: Loading of the compiled Python module from main.py After the module is loaded, its get_path method is invoked


(see Figure 3).


Using ReversingLabs Software Supply Chain Security, my team was able to detect and extract this code from the decompiled PYC file.


The get_path method, which isn’t found (in readable form) anywhere inside the original fshec2 package, performs some of the common malicious functions observed in other malicious PyPI packages we have analyzed.


Among other things, it collects usernames, hostnames, and directory listings.


It also fetches commands that are set for execution using scheduled tasks or cronjob, depending on the host platform.


Figure 3: The decompiled code extracted from the full.pyc compiled byte code file showing the content of the get_path() method.


The fetched commands are just another Python script, which is intended to change (see Figure 4).


In fact, while I have been writing this blog, my team observed it download and execute yet another Python script from the cron_script located on the same host.


The cron_script contained functionality almost identical to the script found in full.pyc, the compiled Python module shipped with the PyPI package.


In this way, the fshec2 attack is engineered to be able to evolve.


The full.pyc file contains functionality to download commands from a remote server identified in the commands path on the C2 server.


The downloaded commands are a Python file almost identical to full.pyc but with the location for downloading stage 2 commands placed in a cron_script, which periodically downloads new commands.


This allows the attackers to change the content served at the commands location to make the malware serve new commands.


Figure 4: Code responsible for downloading cron_script file A misconfigured web host gives up the goods Given the malware’s reliance on remote C2 infrastructure, it made sense to scout out the web host used in the attack to get more information about the malware’s capabilities.


As it turned out, the web host had plenty to tell us!


Like regular developers, malware authors often make configuration mistakes when setting up infrastructure.


Such mistakes can reveal interesting information about the inner workings of malicious software.


That was the case with the web host that was set up to communicate with compromised systems.


For example, trying to access an invalid page on the web host did not generate a 404 “page not found” error, as you would expect.


Instead, visitors were served a page from a Django application listing a variety of commands (see Figure 5).


Figure 5: Uncovered web locations Fortunately for us, the Django application was configured in debug mode, with error descriptions that gave us a detailed list of reachable host paths.


Some of those we had already seen in the downloaded scripts used in the attack, but there were new paths that we had not seen, including: admin, uploaded_files, and download.


Unfortunately, the trail went cold there, because all three of them require authorization to execute page functionality.


Figure 6: Password-protected file download form Still, some information was exposed by this oversight, even without knowing the password.


For example, command No. 7 in Figure 5 provides a way to download files by their ID using the command: download/<int:file_id>, where file_id is an integer and the files in question are numbered in sequential order, starting from 1.


As seen in Figure 6, the filename is also leaked without requiring authorization.


The sheer number of these mistakes might lead us to the conclusion that this attack was not the work of a state-sponsored actor and not an advanced persistent threat (APT).


While my team didn’t collect enough evidence to prove that assumption one way or another, harvesting the filenames by incrementing file ID let us determine that the attack was successful in some cases.


Our researchers still can’t say who or what the targets were.


However, we can confirm that developers did install the malicious PyPI package and that their machine names, usernames, and directory listings were harvested as a result.


Using the method described above, our researchers downloaded files with ID Nos. 1-18.


The resulting filenames show that at least two targets were infected with username and hostname combinations desktop__desktop-7G-Series and Txxxx_Axxxx__LAPTOP-UH9S5HF2 (identifying information removed).


Some of the filenames suggest that additional malware commands include keylogging functionality.


Finally, my team can’t exclude the possibility that there were other channels of distribution besides the fshec2 PyPI package that we haven’t encountered. Figure 7: Names of the files that can be downloaded Conclusion Even though this malicious package and the corresponding C2 infrastructure weren’t state of the art, they remind us how easy it is for malware authors to avoid detection based on source-code analysis.


Loader scripts such as those discovered in the fshec2 package contain a minimal amount of Python code and perform a simple action: loading of a compiled Python module.


It just happens to be a malicious module.


Inspector, the default tool provided by the PyPI security team to analyze PyPI packages, doesn’t, at the moment, provide any way of analyzing binary files to spot malicious behaviors.


Compiled code from the .pyc file needed to be decompiled in order to analyze its content.


Once that was accomplished, the suspicious and malicious functionality was easy to see.


Figure 8: Inspector tool provided by PyPI security team


The discovery of malicious code in the fshec2 package underscores why the ability to detect malicious functions such as get_path is becoming more important for both security and DevSecOps teams.


Most application security solutions either do not focus on supply chain security or only perform source-code analysis as part of the package security inspection.


That is why malware hidden inside the Python compiled byte code could slip under the radar of the traditional security solutions.


ReversingLabs Software Supply Chain Security supports static analysis and unpacking for a wide range of binary file formats, including the kind of compiled Python byte code seen in this attack.


As seen with fshec2, analyzing this kind of file allows defenders to extract indicators of malicious intent, making security assessment much easier.


Figure 9: Behavior indicators and networking strings extracted from the decompiled PYC file using ReversingLabs Software Supply Chain Security.


This includes detection of process creation, file execution, gathering of sensitive information, presence of IP addresses, and much more.


Simple scanning of source code from open-source packages will miss this type of threat.


And, as the attackers press their advantage and become more sophisticated, even more advanced tools will be needed to make sure your developed code and software development infrastructure remains protected.


Indicators of Compromise (IoCs) Package name Version SHA1 fshec2 1.0.0 7be50d49efd1e8199decf84dc4623f58b8686161bab57a9aac8e138e4e2a9f8079fd50b7c1d31540 C2 server: 13.51.44.246 **


This is a Security Bloggers Network syndicated blog from ReversingLabs Blog authored by Karlo Zanki.


Read the original post at: https://www.reversinglabs.com/blog/when-python-bytecode-bites-back-who-checks-the-contents-of-compiled-python-files


Cobalt Strike is a penetration testing tool created by Raphael Mudge in 2012.


To this day, it remains extremely popular in red team activities and used for malicious purposes by threat actors.


Cobalt Strike is popular due to its range of deployment options, ease of use, ability to avoid detection by security products, and the number of capabilities it has.


It is for these reasons that threat actors also like Cobalt Strike.


Since Cobalt Strike is widely used by a range of actors, its lack of exclusivity makes attribution harder.


Companies still struggle to detect Cobalt Strike also due to the various defensive techniques it has.


This blog explains Cobalt Strike and practical steps to take if you believe that you are being targeted by Cobalt Strike or already compromised.


We will demonstrate some real world examples of Cobalt Strike delivery and steps to detect each.


What is Cobalt Strike? Cobalt Strike is marketed as “Software for Adversary Simulations and Red Team Operations.”


It is a popular platform that allows users to emulate advanced threats, perform reconnaissance, hide communications, escalate privileges, move laterally across the network, and deploy additional payloads.


The main payload of Cobalt Strike is called “Beacon.”


The Beacon payload is used to model advanced APT malware, and can do the following: Receive commands (either passively or from an interactive console) Egress communications over HTTP, HTTPS, and DNS Launch PowerShell Execute binaries Modify and query the Windows registry Inject malicious code into legitimate processes Log keystrokes Take screenshots Set up proxies Escalate privileges Bypass UAC Dump password hashes Scan ports among other abilities This tool is mainly used in red team operations for government agencies and private enterprises, but it’s also a popular tool leveraged by cybercrime and APT groups in cracked versions.


It is evident why Cobalt Strike is used by organizations and threat actors alike because of the extensive suite of capabilities it possesses, and also due to its ability to bypass defenses.


It also comes with the feature to generate reporting in which the attacking team or threat actor can continuously study and improve their campaigns.


Why is it difficult to detect Cobalt Strike? Cobalt Strike is difficult to detect because of its several defense techniques.


Cobalt Strike payloads are usually shellcode encrypted with a rolling XOR key.


This makes static analysis difficult to conduct.


This, combined with the ability to configure many parts of the payload, makes hash-based detection almost impossible.


Cobalt Strike stagers are designed to be loaded and executed only in-memory.


This opens up a ton of possibilities for how this shellcode is shipped, making signature-based detection on the delivery method a cat and mouse game.


Depending on how the code is delivered, the code can be injected into other legitimate running processes, bypassing defenses that do not scan legitimate processes or code in-memory.


How has Cobalt Strike been deployed?


Cobalt Strike has many different ways for deployment.


This flexibility has helped attackers find many unconventional and creative ways to infect victims with a payload.


For an in-depth technical analysis of Cobalt Strike’s deployment options and how they differ, check out Avast’s blog or this Cisco Talos white paper.


Let’s take a look at some real world examples of how Cobalt Strike is being used in the wild.


We will cover the following: Macro-Laden Microsoft Office files Supply Chain Attack Living off the Land (LotL) Executables (EXE) files Macro-Laden Microsoft Office Files An example of a Cobalt Strike payload being delivered to victims via Microsoft Excel spreadsheets demonstrates that this tool is also used in mass phishing campaigns, not just targeted APT attacks.


The attack starts by sending potential victims a Microsoft OneDrive link from which an Excel (.xls) file is downloaded.


OneDrive URLs sent to victimsUsing cloud storage links to deliver malicious files is a well-known strategy.


It leverages the good reputation of cloud provider domains such as Microsoft, Amazon, and Google to bypass domain reputation-based security controls.


This link delivers an Excel file pretending to be an Apple Store invoice requesting the target “enable content to view receipt.


”Spreadsheet lure masquerading as an Apple Store receiptUpon enablement of macros, the spreadsheet will fetch and execute the payload in-memory.


How to Detect?


This can be difficult to detect, as there are multiple degrees of separation before the Cobalt Strike payload is executed.


Detection first requires dynamic analysis in order to reach the Cobalt Strike stage.


When this stage is reached, the best ways to detect the running Cobalt Strike code are through static signatures or genetic code analysis.


When it comes to static signatures, it can be difficult to isolate the exact area in-memory that you should run the signatures over.


One way this can be achieved is running the file through debugging tools and manually dumping memory to perform signature analysis.


This can be extremely time consuming and requires a high degree of technical knowledge.


Another possible way is to use a sandbox and download memory dumps from a finished analysis in order to run static analysis tools.


This requires slightly less technical knowledge but it still can be time consuming.


We suggest taking the suspicious document and uploading it to Intezer Analyze to find out if Cobalt Strike is hidden in-memory.


Intezer Analyze result for Cobalt Strike payload Supply Chain Attack One of the biggest cybersecurity stories of 2020 was the SolarWinds supply chain attack that compromised high-profile entities around the world.


This attack was done by an APT group known as NOBELIUM (UNC2452) leveraging the “Orion” business software to distribute malware to private and public organizations.


Among the deployed malware was a Cobalt Strike loader dubbed TEARDROP by FireEye.


The variant was named Raindrop by Symantec.


The TEARDROP dropper is a memory-only DLL that runs as a service spawning a thread that pulls the Cobalt Strike payload from a fake JPG file.


The Raindrop variant is built from a modified version of 7-ZIP source code.


It uses a different custom packer than TEARDROP, also leveraging steganography to locate the start of the encoded payload.


Once the encoded payload has been located, it extracts, decrypts, and decompresses the data to be executed as shellcode.


It can often be difficult to detect if your organization has been the victim of a supply chain attack.


It can be especially hard to collect forensic evidence for an attack when it could be mixed in with the code of legitimate and large files.


Due to the nature of supply chain attacks, there are often a large number of machines in an organization infected at one time.


An action you can take is to run Intezer’s live endpoint scanner across all machines in the organization.


This will give you immediate visibility over all running code and quickly identify infected machines by detecting any traces of malicious code found in-memory.


An example of a machine with Raindrop loading Cobalt Strike is shown in the endpoint scan below.


Intezer Analyze endpoint scan result for Raindrop loading and executing a fileless Cobalt Strike payload Living off the Land (LotL) Living off the Land (LotL) is the attack process of using legitimate and signed tools, usually provided within the operating system, to execute malware.


This is a powerful tactic as it can result in unauthorized code being executed within the memory space of a trusted process, evading malware defenses by flying under the radar.


This type of tactic also makes incident response difficult, since analysts can’t just filter out known legitimate processes during triage.


All processes must be inspected in order to find that one needle in the haystack.


One popular tool used for LotL operations is the Microsoft.


NET framework utility called MSBuild.


MSBuild is the build platform used for Microsoft and Visual Studio.


Visual Studio relies on MSBuild to build projects for testing and releases.


Attackers are able to pass MSBuild.exe, a project (.proj) file, to build and execute.


The payload, usually shellcode, is injected into another process.


This attack is effective for attackers as many sandboxing solutions are not able to handle project files and struggle with fileless malware.


This technique was observed by Cisco Talos researchers in 2020 to deploy Cobalt Strike.


Project file codeAs shown above, the project file has an encoded and compressed payload.


This payload is decrypted, decompressed, and then copied into memory.


The shellcode is then executed in a new thread.


An endpoint with a system injected with Cobalt Strike via MSBuild is shown below.


Note the process tree at the bottom indicating the “fileless code.


”Intezer Analyze endpoint scan of a Cobalt Strike-infected system via LotL technique Executables (EXE) Files There is an acronym in the United States Armed Forces called “KISS.”


KISS stands for “Keep it simple, stupid!”


Sometimes simple is better, and another way for Cobalt Strike to be deployed is in a simple Windows EXE form.


This requires either social engineering tactics to get the target to execute the malware or another program/script to execute the file.


This process involves creation of a thread that sets up a named pipe for privilege escalation.


Once the shellcode is written to the named pipe, it is decrypted and executed in a separate thread.


An example of one of these payloads is shown in the analysis below.


Notice how the Cobalt Strike code is only shown when it is executed and found in-memory.


Cobalt Strike found via memory analysis How can Cobalt Strike be detected and remediated?


Due to the many ways Cobalt Strike is deployed, detection can be hard.


The use of shellcode, encoding, compression, obfuscated strings, process injection, hashing algorithms, domain fronting, different communication channels, and dynamically loaded libraries all give malware and network defenses a run for their money.


Static Analysis Static analysis involves examining the file using various techniques without actually having to execute the file itself.


Static analysis can involve hashing the file and finding intel on it, taking a look at the strings to see if there are functionality or network indicators, or checking imports and running signatures such as YARA for the file.


Although useful, static analysis on its own is probably not sufficient to detect Cobalt Strike.


Using hash-based identification of Cobalt Strike is insufficient, since each payload will be encrypted with different keys and each configuration will uniquely change the hash value.


It is trivial to generate a new payload for each new target.


Checking strings may be insufficient also.


Strings for pipe names are dynamically generated and incorporate random numbers, meaning they can change every time the malware is executed.


Encrypted payloads will also obfuscate useful strings from static analysis.


API Hashing algorithms employed by Cobalt Strike hide imports from static analysis techniques.


Signature-based detection is great for detecting malware, but due to the versatility of Cobalt Strike’s deployment using multiple stages and encrypted/obfuscated payloads, an analyst may only be able to detect that a file is going to load and execute a payload in-memory.


Without dynamic analysis, they won’t be able to detect exactly what that payload will be.


Dynamic Analysis Dynamic analysis is the process of executing the suspect file in order to analyze its behavior and how it affects the environment it runs in.


Dynamic analysis can open up new areas to explore as one can follow the malware through each stage of its deployment and functionality.


Dynamic analysis can get the malware to unpack, decode, or download additional stages.


These new stages are then subject to further dynamic analysis as well as the previously mentioned static analysis techniques.


Dynamic analysis does not have many limitations, although some malware includes functionality to detect if it is being observed or running inside a sandboxed environment.


There is also the possibility that during dynamic analysis, areas of malicious code may not be intentionally executed, and thus not detected in the behavior.


The best way to detect malicious code is via genetic code analysis which is done automatically for you in Intezer Analyze. Combination of Several Techniques The best way to detect Cobalt Strike code is through a combination of dynamic, static, and genetic analysis.


Let’s take a suspicious looking document from an unknown entity as an example.


Before opening the document, we submit it to Intezer Analyze and get the verdict, as shown below.


Intezer Analyze result showing in-memory Cobalt Strike codeThe document drops and executes Cobalt Strike in the memory space of “rundll32.exe.”


Signatures are leveraged to show capabilities and file characteristics.


Under the “TTPs” tab the user can see the techniques/capabilities employed by the malicious document.


TTPs section showing capabilities detected during executionThe document displays interesting techniques such as macros with auto-execution, network activity with a unique user agent, office process starting martian subprocess, and process injection.


You can also dive deeper into capabilities specific to the injected Cobalt Strike process.


The “IoCs” tab in Intezer Analyze shows indicators that can help you pivot and search in your environment during investigations to map out the scope of an attack.


IoCs provide you with file hashes and network indicators such as URLs, and IP addresses being contacted through irregular ports.


IoCs tab showing file and network


indicatorsThe “Behavior” tab shows a more in-depth analysis of the file’s behavior, where you can see the process tree, network activity, screenshots and file/registry activity.


Behavior tab showing observed behavior during sandbox execution The Only Abused Pen Testing Tool? Cobalt Strike is not the only penetration testing or legitimate tool that has been co-opted and abused by threat actors.


In the past, tools such as Pafish (Paranoid Fish) have been used by Iranian actors in their tooling for virtual machine (VM) detection.


The “Sysinternals” suite has been used extensively by threat actors.


Most notably, PsExec has been used in high-profile attacks such as the 2017 NotPetya global ransomware outbreak.


More recently, legitimate and penetration testing tools for the cloud have been used by threat actors.


The threat actor TeamTNT has used Weave Scope, a trusted tool which gives the user full access to their cloud environment, and is integrated with Docker, Kubernetes, the Distributed Cloud Operating System (DC/OS), and AWS Elastic Compute Cloud (EC2).


The attacker installs this tool in order to map the cloud environment of their victim and execute system commands without needing to deploy malicious code on the server.


The same group has also been documented using the penetration testing tool Break Out The Box (BOTB) for cloud and containerized environments.


Get Started for Free With Intezer Analyze, you can analyze any suspicious files that you encounter, including non-executable files such as Microsoft Office documents, scripts, archives, and more.


Stay on top of analyzing and classifying Cobalt Strike and other threats.


Get started for free and start with 50 file uploads per month.


The post How to Detect Cobalt Strike appeared first on Intezer.


The CatB ransomware family, sometimes referred to as CatB99 or Baxtoy, was first observed in late 2022, with campaigns being observed steadily since November.

CatB Ransomware  File Locker Sharpens Its Claws to Steal Data with MSDTC Service DLL Hijacking


The group’s activities have gained attention due to their ongoing use of DLL hijacking via Microsoft Distributed Transaction Coordinator (MSDTC) to extract and launch ransomware payloads.


String similarities in the ransom notes as well as modifications left by the ransomware payloads suggest that CatB may be either an evolution or direct rebrand of the Pandora ransomware, which was active in early to mid-2022 and targeted the automotive industry.


In this post, we offer a technical analysis of the CatB ransomware and its abuse of the legitimate MSDTC service, describing its evasion tactics, encryption behavior, and its attempts to steal credentials and browser data.


CatB Ransomware Technical Information CatB payloads are distributed as a two DLL set.


A dropper DLL is responsible for initial evasive environmental checks as well as dropping and launching the second DLL, which serves the ransomware payload.


CatB Ransomware Process Graph First, the dropper is distributed in the form of a UPX-packed DLL (versions.dll).


This dropper deposits the second DLL payload (oci.dll) onto the target host.


The dropper DLL is responsible for any sandbox evasion techniques required by the threat actor.


Sandbox evasion inhibits the analysis process and ultimately leads to more time in the target environment for the attacker.


CatB performs three primary checks in an attempt to determine if the payload is being executed within a virtual environment.


These are direct checks for type and size of physical RAM, type and size of physical hard disks, and checking for odd or anomalous combinations of processors and cores.


Upon execution, CatB payloads rely on DLL search order hijacking to drop and load the malicious payload.


The dropper (versions.dll) drops the payload (oci.dll) into the System32 directory.


Oci.dll payloads in System32 (view from Singularity Console)


The malware then abuses the MSDTC service, manipulating the permissions and startup parameters.


As a result, the system will inject the malicious oci.dll into the service’s executable (msdtc.exe) when the MSDTC service is restarted.


Taskill.exe is used to terminate the msdtc.exe process once the service configuration changes have been made.


Msdtc.exe termination syntax CatB ransomware excludes the following files and extensions from the encryption process: .msi, .dll, .sys, .iso and NTUSER.DAT.


Encryption exclusions in payload DLL


In addition to the hardcoded exclusions, the local disk volumes to be encrypted are also configured in a similar manner.


By default, the oci.dll payload will attempt to encrypt C:\users (crawl whole tree), I:, H:, G:, F:, E:, and D:.


Local encryption targets in oci.dll The lack of post-encryption alterations is a trait that sets CatB apart from other contemporaries.


Once encrypted, there is no blatant indicator – no separate ransom note dropped, no change to the desktop wallpaper, and no antagonizing file extensions.


Instead, what could be considered the ransom note is inserted into the beginning of each encrypted file.


Ransom note appended to head of encrypted file (catb991 variation)


Per the ransom note, the only way to engage the threat actor is via email at the provided catB9991 protonmail address.


Beyond that, a single Bitcoin (BTC) address is provided for payment submissions.


The ransom price is set to increase each day for five days and, following the fifth day, there will be “permanent data loss” if the victim does not comply.


Based on observations, there is no evidence to indicate that CatB operators are generating payment wallets for each victim as the Bitcoin address provided is not unique to each sample.


Generation of unique key file A key file is deposited onto each infected host in c:\users\public\. This file must be included in email correspondence with the attackers as it is, ideally, a unique identifier for each victim or host.


Key file dropped for each victim Example CatB ‘key’ file Credential and Browser Data Theft


In addition to file encryption and obfuscation, the CatB malware will attempt to gather specific, sensitive information from targeted systems.


This includes browser session and credential data.


The ransomware contains functionality to discover and extract user data from Mozilla Firefox, Google Chrome, Microsoft Edge as well as Internet Explorer.


Data extracted from browsers includes bookmarks, blocklists, crash logs, history, user profile data, autofill data, environmental settings, browser session keys, and more.


CatB malware will also attempt to locate and extract sensitive information from Windows Mail profile data (\AppData\Local\Microsoft\Windows Mail\).


Variations of CatB Threat Campaigns Samples pulled from a November 2022 campaign feature a different contact email address, fishA001[@]protonmail.com.


This later changes to the catB9991 protonmail address mentioned above.


This is the only difference with regards to the ransom notes.


Other details such as payment-per-day breakdowns and the BTC payment address are identical.


Alternate ransom note (fisha001)


We have also encountered variations which include both email addresses.


When these ‘double email’ notes are appended to the head of files, it looks as follows: Alternate ransom note (double-email, no BTC)


These ransom notes display all the same features minus the BTC payment address.


Also missing is the requirement to submit the key file in c\users\public\key.


Notes that are missing the key submission feature suggest that they are artifacts of an earlier ‘test’ version of the ransomware.


BTC Payment / Blockchain Status As the time of writing, the BTC address associated with CatB ransomware have zero transactions and a zero balance.


BTC Balance for Wallet – bc1qakuel0s4nyge9rxjylsqdxnn9nvyhc2z6k27gz Conclusion CatB joins a long line of ransomware families that embrace semi-novel techniques and atypical behaviors such as appending notes to the head of files.


These behaviors appear to be implemented in the interest of detection evasion and some level of anti-analysis trickery.


For example, many environments rely solely on the appearance of ransom notes to alert them to the potential of a ransomware outbreak.


This is not the case with CatB. Despite that, the threat lacks in overall sophistication, and a modern, properly configured, XDR/EDR solution should alert quickly upon initiation of a CatB attack in the environment.


SentinelOne Singularity fully prevents and protects customers against malicious behaviors associated with CatB Ransomware. Indicators of Compromise SHA1 CatB Samples 1028a0e6cecb8cfc4513abdbe3b9d948cf7a5567 8c11109da1d7b9d3e0e173fd24eb4b7462073174 951e603af10ec366ef0f258bf8d912efedbb5a4b (early version note example) db99fc79a64873bef25998681392ac9be2c1c99c dd3d62a6604f28ebeeec36baa843112df80b0933 Email addresses catB9991[at]protonmail[.]com fishA001[at]protonmail[.]com BTC Wallets bc1qakuel0s4nyge9rxjylsqdxnn9nvyhc2z6k27gz