Overview

The Computer Emergency Response Team of India (CERT-In) has issued an urgent vulnerability note (CIVN-2024-0349) regarding multiple security flaws in Android. These vulnerabilities, identified as “High” in severity, affect Android versions 12, 12L, 13, 14, and 15, potentially putting millions of devices worldwide at risk.

This advisory serves as a wake-up call for OEMs (Original Equipment Manufacturers), Android users, and cybersecurity professionals. If exploited, the vulnerabilities could lead to unauthorized data access, privilege escalation, arbitrary code execution, and system crashes.

Overview of the Threats

Android is the world’s most widely used mobile operating system. It powers billions of devices globally, including smartphones, tablets, smartwatches, and IoT devices. Its open-source nature and vast ecosystem make it a prime target for attackers.

CERT-In has highlighted that multiple vulnerabilities have been detected in various critical components of Android, including:

• Framework
• System
• Google Play System Updates
• Kernel and Kernel LTS
• Chipset Components: MediaTek, Qualcomm, Imagination Technologies
• Closed-Source Qualcomm Components

The exploitation of these vulnerabilities could allow threat actors to:

• Extract sensitive information such as user credentials and private data.
• Gain elevated privileges, enabling unauthorized control over the device.
• Execute arbitrary code, leading to malware installation or unauthorized actions.
• Cause Denial of Service (DoS), rendering the device unstable or inoperable.

Implications for Users and OEMs

Risk Assessment

The vulnerabilities have been classified as High Risk, indicating significant potential for widespread damage:

• Unauthorized Access: Attackers could exploit the flaws to infiltrate devices and access sensitive user data.
• System Instability: Successful exploitation might cause devices to crash or malfunction, disrupting regular operations.

Impact Assessment

• Data Breaches: Private user data could be exposed or stolen, posing privacy and financial risks.
• System Downtime: Affected devices could experience crashes, slowing down productivity and service availability.

This situation demands immediate attention from OEMs, who must release timely patches, and from users, who must ensure their devices remain updated.

The Scope of the Vulnerabilities

The CERT-In advisory lists over 40 vulnerabilities tracked under the Common Vulnerabilities and Exposures (CVE) system. A few of the critical CVEs include:

• CVE-2023-35659
• CVE-2024-20104
• CVE-2024-21455
• CVE-2024-38402
• CVE-2024-43093

Each CVE points to a specific flaw in Android’s components. For instance, vulnerabilities in Qualcomm and MediaTek chipsets could allow remote attackers to bypass critical security controls. Kernel vulnerabilities could enable privilege escalation, granting attackers complete control over the device.

Recommended Actions

For Users

1. Update Your Device: Check for system updates regularly and apply them as soon as they become available. OEMs release patches to mitigate these vulnerabilities.
2. Download Apps Only from Trusted Sources: Avoid third-party app stores and download apps exclusively from Google Play.
3. Enable Security Features: Utilize features like biometric authentication, two-factor authentication (2FA), and device encryption.
4. Avoid Clicking Suspicious Links: Phishing attacks often exploit such vulnerabilities to compromise devices.

For OEMs and Enterprises

1. Prioritize Patch Management: Ensure timely delivery of security patches to devices running vulnerable Android versions.
2. Conduct Risk Assessments: Evaluate the potential impact of these vulnerabilities on your devices and systems.
3. Collaborate with Google: Work closely with Google to address vulnerabilities and maintain the integrity of Google Play system updates.
4. Communicate with Users: Inform customers about the risks and provide clear instructions on applying updates.

Technical Analysis: Why These Flaws Matter

The vulnerabilities stem from diverse sources, including outdated software components, misconfigurations, and unpatched exploits. Here’s a breakdown:

1. Framework and System Flaws: These are at the core of Android and may enable attackers to access sensitive OS-level permissions.
2. Kernel and Kernel LTS Issues: Kernel vulnerabilities are particularly dangerous as they grant low-level access, making privilege escalation easier.
3. Chipset-Specific Weaknesses: Vulnerabilities in MediaTek and Qualcomm components highlight how third-party hardware can introduce risks into Android devices.
4. Google Play Updates: An attacker exploiting flaws in Google Play system updates can compromise the very mechanism meant to secure devices.

Attackers typically exploit these flaws via:

• Remote Code Execution (RCE): Delivering malicious payloads through apps or websites.
• Privilege Escalation: Gaining unauthorized control of devices.
• Denial of Service (DoS): Overloading system resources to render the device inoperable.

Looking Ahead: The Role of Collaborative Efforts

The CERT-In advisory emphasizes the need for collaboration among stakeholders, including Google, OEMs, and the cybersecurity community. A comprehensive approach involving timely patching, user education, and proactive risk management is essential to mitigate these risks.

Key Takeaways

1. Android versions 12 through 15 are vulnerable to multiple high-severity security flaws.
2. The vulnerabilities could lead to data theft, privilege escalation, or denial of service.
3. Users must apply updates promptly and exercise caution while browsing or installing apps.
4. OEMs should expedite patch rollouts to ensure device security.

Even a single unpatched vulnerability can cascade into large-scale cyber incidents. Staying vigilant and acting swiftly is the only way to ensure Android devices remain safe from exploitation.

References

https://www.cert-in.org.in

The post CERT-In Alert: Multiple Vulnerabilities in Android Impacting Millions of Devices appeared first on Cyble.

Blog – Cyble – ​Read More

TI Lookup from ANY.RUN is a versatile tool for gathering up-to-date intelligence on the latest cyber threats. The best way to demonstrate its effectiveness is to hear from actual security professionals about how they use the service in their daily work.  

This time, we asked Jane_0sint, an accomplished network traffic analyst and the first ANY.RUN ambassador, for her real-world cases of using TI Lookup. Lucky for us, she agreed to share her insights and sent us a few examples, which include finding intel on phishing kits like Mamba2FA and Tycoon2FA. 

About Threat Intelligence Lookup 

TI Lookup is a searchable hub for investigating malware and phishing attacks and collecting fresh cyber threat data. Powered by a massive public database of millions of samples analyzed in ANY.RUN’s Interactive Sandbox, it contains various Indicators of Compromise (IOCs), Indicators of Attack (IOAs), and Indicators of Behavior (IOBs), from threats’ network activity to system processes and beyond. 

The service provides you with extensive search capabilities, allowing you to create custom requests that feature different data points to home in on specific threats. It offers: 

• Quick Results: Searches for events and indicators from the past six months take just 5 seconds on average

• Unique Data: It contains over 40 types of threat data, including malicious IPs, URLs, command line contents, mutexes, and YARA rules

• Large Database: TI Lookup is updated daily with thousands of public samples uploaded to ANY.RUN’s sandbox by a global community of over 500,000 security professionals

Investigating the Mamba2FA Phishing Kit 

Mamba2FA is a phishing kit that has seen a significant rise over the past several months. To investigate this threat and gather more context, we can utilize a typical URL pattern commonly found in its campaigns. This pattern follows the structure {domain}/{m,n,o}/?{Base64 string}.

When translating this into an actual query for TI Lookup, we can use the following search string: 

Let’s break down this query: 

• Asterisk (*): This wildcard character indicates any character string. It helps expand our search to include all domains used in Mamba2FA attacks, ensuring a comprehensive investigation

• Question Mark (?): This is another wildcard character that indicates exactly one character or none at all. In our case, there are two question marks in the query. The first one is the wildcard that serves as a stand-in for the characters “m”, “n”, and “o” that are commonly used in Mamba2FA URLs. The second question mark is a part of the address. To escape it, we use the slash symbol

• c3Y9: This is a Base64-encoded parameter found across Mamba2FA attacks. When decoded, it translates to sv=, which specifies the appearance of the phishing page

Submitting this search query to TI Lookup allows us to access plenty of results that match our string, from command lines with URLs to sandbox sessions where these command lines were logged. 

We then can collect the full URLs found and decode the base64-encoded parts to reveal more information on the attack and extract the list of domains from them. 

Investigating the Tycoon2FA Phishing Kit 

Tycoon2FA is another phishing kit, which is known for faking Microsoft authentication pages to steal victims’ credentials. With the help of TI Lookup, we can collect plenty of intel on its latest samples and wider infrastructure.  

A good practice for constructing queries in TI Lookup is to link each condition of the query to specific features of the phishkit: 

• If the phishkit hides its pages behind Cloudflare Turnstile, we add a condition for this; 

• If there is content encryption, we add a condition for the encryption library; 

• If the phishing page stores content on a specific CDN (Content Delivery Network), we add a condition for that as well.  

An example of this query construction method for searching Tycoon2FA phishkit attacks can be seen below. 

As noted, one of the signature features of this threat is the abuse of Cloudflare’s Turnstile challenges as a barrier for automated security solutions. For the challenge to work, Tycoon2FA loads the library api.js. 

During the challenge, Tycoon2FA also loads another library, crypto-js.min.js, which it uses at later stages of the attack to encrypt its communication with the command-and-control center (C2). 

The phish kit also accesses elements stored on the legitimate domain ok4static[.]oktacdn[.]com and utilizes them to build phishing pages designed to imitate Microsoft’s login pages. 

The two libraries and the domain make solid pieces of intel to pivot on using TI Lookup to find instances of Tycoon2FA attacks. 

In response to the query, the service provides a list of matching events found in 20 decrypted sandbox sessions over the past 180 days. Search queries created on this principle based on domains bring more results because they work not only on decrypted network sessions but also require a larger number of conditions in the query. We can collect the information and take a closer look at the sessions to observe attacks as they unfolded in real time. 

Tracking APT-C-36 Phishing Campaigns 

Threat Intelligence Lookup can be helpful in your investigations into campaigns that are attributed to advanced persistent threats (APTs). 

Consider the example of Blind Eagle, also known as APT-C-36, which is a group that targets Latin America. You can learn more about their activity in ANY.RUN’s article on the threats discovered in October 2024.  

Knowing that APT-C-36 uses phishing emails with attachments that contain malware, such as AsyncRAT and Remcos, and attempts to reach targets in LATAM countries like Colombia, we can put together a TI Lookup query to find more relevant samples related to their attacks: 

The service provides 100 sandbox sessions that match our request along with events from those sessions. 

Among them, we can find samples of actual phishing emails belonging to Blind Eagle’s campaigns which were publicly uploaded to ANY.RUN’s sandbox for analysis by users in Colombia. 

Identifying Phishing Attacks Abusing Microsoft’s Infrastructure 

Another useful way to utilize TI Lookup is to proactively research phishing attacks that use legitimate resources to access content as legitimate account login pages do. For example, attackers often use parts of the Azure Content Delivery Network (CDN), like backgrounds or login forms. 

To find these examples with TI Lookup, you can specify the Azure domain. However, it’s important to filter out non-malicious instances. You can do this by excluding Microsoft’s domains from the query using the NOT operator and setting the threat level to “suspicious.” You are free to add exceptions at your discretion if you wish to cleanse your query results of unsolicited submissions. 

We can also include parameters with empty values. This signals the system to show all possible results for those parameters.

Adding domainName:”” and suricataMessage:”” will display all domains and Suricata messages found across sandbox sessions that match our query. 

In response to our query, TI Lookup provides extensive threat data, including the Suricata rules that were triggered during analysis.

We can also observe all the domains in sessions involving phishing attacks. We can collect them and examine each of them separately to check if they are used as part of attackers’ infrastructure. 

We also get a list of sandbox sessions that feature examples of actual phishing attacks abusing Microsoft’s infrastructure.  

Let’s explore one of them in greater detail. 

In this session we can see a Suricata rule that indicates a request to Azure’s content delivery network.  

You can build upon this search by adding a commandLine parameter. Specifically, we can tell the service to look for command lines that include URLs with the # anchor, which attackers use to add a victim’s email address. 

To find results with URLs containing email addresses, include the @ symbol in your query. Use the * wildcard to account for any characters between the anchor and the @ symbol. 

Apart from relevant sandbox sessions, the service returns a list of command lines extracted from these, allowing us to see the URLs used by attackers that include emails of victims. 

About ANY.RUN  

ANY.RUN’s Threat Intelligence Lookup and YARA Search services allow for precise threat hunting and the extraction of valuable insights into current cyber threat trends. What’s impressive is how fast these scans are—they significantly speed up the analysis process, allowing for quick detection of threats and malware. 

See Black Friday deals for ANY.RUN’s Interactive Sandbox and Threat Intelligence Lookup →

The post Investigating Phishing Threats with TI Lookup: Use Cases from an Expert appeared first on ANY.RUN’s Cybersecurity Blog.

ANY.RUN’s Cybersecurity Blog – ​Read More

Key takeaways

• Cyble Research and Intelligence Labs (CRIL) has identified a malicious campaign likely targeting business professionals across the United States.
• The campaign employs a malicious LNK file, masquerading as a PDF with encoded data. This file is decoded by leveraging certutil.exe, which then delivers the next-stage payload: an HTA file.
• The HTML Application (HTA) file contains VBScript that extracts and executes a lure document and a malicious DLL file, both embedded within the HTA file.
• The DLL file acts as a Loader, decrypting the subsequent payload and shellcode, which are responsible for executing the Ursnif core component.  
• The Threat Actor (TA) behind this campaign uses a multi-stage operation that executes entirely in memory, effectively evading detection by security products.
• The final payload file (DLL) is identified as Ursnif malware, capable of establishing a connection with the C&C server and downloading additional modules to steal sensitive information from the victim’s machine.

Overview

CRIL recently identified an active malicious campaign utilizing a malicious LNK file as the initial infection vector, delivered within a ZIP archive, potentially through spam emails. This LNK file is cleverly disguised as a PDF, tricking users into thinking they are opening a legitimate document.

Based on the lure document observed in this campaign, CRIL has concluded that the campaign is likely targeting business professionals across the United States.

When executed, the LNK file runs a command via cmd.exe to invoke the legitimate certutil.exe tool on the compromised system. This process decodes and prepares the next-stage payload embedded within the LNK file. The decoded payload is identified as a malicious HTML Application (HTA) file, which is executed using the legitimate mshta.exe utility. Upon execution, the HTA file opens a PDF lure document to trick the victim and simultaneously drops a malicious DLL file embedded within its content. The DLL is then executed using regsvr32.exe.

The DLL functions as a loader, decrypting both the shellcode and another encrypted DLL file from its resource section, and then executing the shellcode. Once the shellcode is executed, it loads the decrypted DLL, which subsequently loads another embedded malicious DLL identified as Ursnif—a notorious banking trojan. Ursnif then establishes a connection to its Command and Control (C&C) server and retrieves additional payloads designed to steal sensitive information from the victim’s machine. The below image shows the infection chain of this campaign.

Technical Analysis

The ZIP archive contains an LNK file disguised as a PDF. Once extracted, the file appears as “staplesds02_23.pdf,” but it is actually an LNK file with a dual extension (.pdf.lnk) crafted to mislead users into believing it is a legitimate PDF document. When the user opens the disguised LNK file, it triggers cmd.exe and leverages certutil.exe to decode and execute malicious content embedded within the file. The following image shows the command line configured within the malicious LNK file.

Certutil is a Windows command-line utility primarily used for managing certificates. However, it is frequently abused by TAs to decode files encoded in Base64 format. In this case, the malicious LNK file contains Base64-encoded data, enclosed within the “—–BEGIN CERTIFICATE—–” and “—–END CERTIFICATE—–” tags, as shown in the figure below.

The decoded content results in an .hta file (HTML Application), which is saved in the system’s temporary directory (C:UsersuserprofileAppDataLocalTemp) and executed using mshta.exe. The image below shows the content of the dropped HTA file.

The initial section of the HTA file contains a VBScript designed to retrieve data from a remote server at hxxps://docusign-staples[.]com/api/key via an HTTP GET request. Once a response is received, the script verifies that the HTTP status code is 200 (OK) and that no errors occurred before executing further actions. If an error occurs or the status code is not 200, the script terminates its execution.

Upon receiving the response from the remote server, the VBScript decodes the response body into a readable string. It then extracts the first five characters from the decoded data and compares them to the hardcoded string “QG099.” If the strings do not match, the script terminates execution; otherwise, it continues with further actions.

When the first five characters of the decoded response body match the hardcoded string, the VBScript extracts a portion of the file’s content, starting at byte offset 7956 (1F14h) with a length of 138617 bytes. The image below displays a portion of the extracted content at this offset.

The extracted content, identified as a PDF, is saved in the temporary folder as staplesds.pdf. The script then opens this PDF, presenting it as a lure document to the victims. The figure below shows the lure document.

The Figure below shows another lure document observed in this campaign.

Then, the VBScript disables Windows Defender protection by adding the C: drive to the exclusion list through PowerShell commands.

• Add-MpPreference -ExclusionPath “C:” ; timeout 15

After adding the exclusion path, the VBScript extracts another large chunk of data from the file, starting immediately after the PDF content, and retrieves a block of 1,416,704 bytes. As shown below, this extracted data corresponds to a PE (Portable Executable) file.

The retrieved PE file is then saved as a DLL file named “x.dll” in the temporary location. Additionally, the script pads the newly created DLL file with empty spaces by writing 35 blocks, each containing 10 million space characters.

Finally, the HTA script sets the current working directory to the user’s Desktop and executes a command to use regsvr32, registering the newly created DLL file as a system component.

Loader DLL

Upon execution, the DLL calls the ntdll.LdrFindResource API to access a resource named “FAMILY.” This resource contains two encrypted pieces of content, which are stored within the executable, as shown below.

The DLL reads the encrypted contents and decrypts them using a hardcoded key present in the file. The following figure shows the code snippet responsible for decrypting the encoded data.”

The first encrypted content is a shellcode that, when decrypted, is responsible for mapping another PE (Portable Executable) file into memory, as illustrated below.

The second encrypted content is a PE DLL file, which acts as another loader for executing the core module of the Ursnif component. This core component is responsible for establishing a connection to the C&C server and downloading additional Ursnif modules to steal sensitive information from the victim’s machine. The figure below shows the decrypted file, with control being transferred to the shellcode after decryption.

Shellcode Execution

Next, the shellcode copies the hardcoded API strings that are necessary for dynamically resolving the required APIs.

The shellcode then passes the hardcoded checksum “0xBDBF9C13” of the “LdrLoadDll” to a custom function. This function scans the loaded DLLs in memory that have export functions. If an export function is found, it calculates the checksum based on the DLL name, then iterates through the APIs associated with that DLL, calculating the checksum for each API.

It adds the checksum of each API name to the DLL name checksum and compares the result with the hardcoded checksum. If there is a match, the shellcode identifies the corresponding address to dynamically resolve the “LdrLoadDll” function. Similarly, it resolves the “LdrGetProcedureAddressEx” API by passing the checksum “0x5ED941B5.”

After resolving, it uses LdrLoadDll and LdrGetProcedureAddressEx to resolve the following APIs:

• VirtualAlloc
• VirtualProtect
• FlushInstructionCache
• GetNativeSystemInfo
• RtlAddFunctionTable 
• LoadLibraryA

The shellcode then uses the VirtualAlloc API to allocate a new memory region. Afterward, it copies the decrypted DLL (previously extracted from the resource section) into this newly allocated memory, excluding the DOS header. To ensure the DLL can be executed properly, the shellcode modifies the memory protection of the allocated space using the VirtualProtect API, as shown below.

Finally, the shellcode calls the RtlAddFunctionTable API to add a dynamic function table to the list of function tables in memory. Afterward, it uses the FlushInstructionCache API to ensure that the changes made to the memory are permanently written and reflected in the processor’s cache. Once the necessary memory modifications are made, it proceeds to execute the loaded DLL by invoking the DllRegisterServer function, which typically registers the DLL with the system and allows its functions to be used for further malicious activities.

Second Stage DLL

The second-stage DLL contains another embedded DLL, which is the core component of the Ursnif malware. This DLL holds encrypted configuration data, including crucial information such as the C&C server address, user agent, bot-details, and more. Upon execution, the second-stage DLL loads the embedded DLL found in the .data section, maps it into memory, and modifies its protection using the VirtualProtect API. It then transfers control to the entry point of the DLL, as illustrated below.

The final DLL file now reads the encrypted configuration details stored in the .bss section, passes it through a decryption loop, and retrieves the C&C server details from the decrypted configuration, as shown below.

The decrypted configuration file also contains additional information, such as the user agent details and the structure used for communication with the C&C server, as shown below.

After decrypting the configuration file, the malware calculates a checksum based on the creation time of pagefile.sys or hiberfil.sys present on the system. It then generates a checksum of the victim’s username. To ensure that only one instance of the malware is running at any given time, it creates a mutex named “GlobalDbEls,” as shown below.

After creating the mutex, the malware uses GetCurrentThreadId, OpenThread, and QueueUserAPC APIs to launch a new thread. This new thread is responsible for handling communication with the C&C server.

C&C Communication

The malware constructs a specific format for its C&C communication, which is shown in the figure below. This structure is designed to facilitate the exchange of data between the infected machine and the C&C server.

Filed	Description
version	Bot Version
user	Checksum calculated previously based on the victim’s username
group	Bot ID
System	Checksum created based on the creation time of pagefile.sys or hiberfil.sys
file	Checksum of the filename
arc	File architecture
crc	File checksum
size	File size

The malware then prepends a random string “emst=urxll&” to the created format, as shown below.  

• emst=urxll&version=100123&user=810e007f91e84a5f&group=1000&system=61c6080c8c3fd701&file=8fd8a91e&arc=0&crc=00000000&size=0

The malware then utilizes the following APIs to encrypt the format it generated for its C&C communication, using AES encryption:

• CryptAcquireContextW
• CryptImportKey
• CryptsetKeyParam
• GenRandom
• CryptReleaseContext
• CryptEncrypt

After encryption, the malware invokes the CryptStringToBinaryA API to convert the encrypted content into a BASE64-encoded format, as shown below.

Finally, the malware generates a boundary and uses the following boundary and User-Agent string to communicate with its C&C server at “budalixt.top/index.html.” In this instance, the malware utilizes an outdated User-Agent for its communication, as shown below.

In the next stage, the malware receives a response from the C&C server, which is intended to download and execute additional malware to carry out malicious activities. Unfortunately, we were unable to retrieve any response from the C&C server as it was down, preventing us from fully analyzing the next stage of the attack.             

Conclusion

The Ursnif malware campaign exemplifies the growing sophistication in cyber threats. By utilizing advanced techniques such as dynamic API resolution, encrypted payloads, and memory manipulation, Ursnif successfully evades detection and establishes secure communication with its C&C server. Each stage of the malware’s execution, from initial resource loading to the final encrypted C&C communication, is designed to ensure persistence, data exfiltration, and the ability to adapt to changing environments.     

Yara rule to detect the latest ursnif loader, available for download from the Github repository.      

Recommendations

• This campaign reaches users via potential phishing campaigns, so exercise extreme caution when handling email attachments and external links. Always verify the legitimacy of the sender and links before opening them. 
• Implement advanced email filtering solutions to detect and block malicious attachments and links.
• Use EDR solutions to detect the execution of regsvr32 in unusual contexts or locations, especially when the DLL is from non-standard directories (e.g., AppData or Temp).
• Limit the execution of scripting tools to necessary users only and enforce least privilege policies to prevent malware from escalating privileges and performing malicious actions.
• The campaign abused the legitimate certutil and mshta utility; hence, it is advised to monitor the activities conducted by these tools and restrict access to limited users.
• Implement behavior-based detection systems that can identify malicious actions, such as frequent attempts to contact C&C servers or unexpected encrypted data being transmitted.

MITRE ATT&CK® Techniques

Tactic	Technique	Procedure
Initial Access (TA0001)	Phishing (T1566)	This campaign is likely to reach users through spam emails
Execution (TA0002)	Command and Scripting Interpreter: Windows Command Shell (T1059.003)	Executes Certutil,exe to decode the next stage payloads
Defense Evasion (TA0005)	Masquerading: Masquerade File Type (T1036.003)	The .lnk file is named to appear as a PDF file to deceive users.
Defense Evasion (TA0005)	System Binary Proxy Execution: Mshta (T1218.005)	Abuse mshta.exe to proxy execution of malicious hta file
Defense Evasion (TA0005)	Deobfuscate/Decode Files or Information (T1140)	Deobfuscate/Decode Files or Information
Command and Control (TA0011)	Application Layer Protocol: Web Protocols  (T1071.001)	sends HTTP POST requests to communicate with its C&C server.
Exfiltration (TA0010)	Exfiltration Over C2 Channel (T1041)	System information and potentially other data are exfiltrated over the established C&C channel.

Indicators of Compromise

Indicator	Indicator Type	Comments
fdc240fb8f4a17e6a2b0d26635d8ab613db89135a5d95834c5a888423d2b1c82	SHA-256	Zip File
dd20336df4d95a3da83bcf7ef7dd5d5c89157a41b6db786c1401bf8e8009c8f2	SHA-256	Malicious LNK file
13560a1661d2efa15e58e358f2cdefbacf2537cad493b7d090b5c284e9e58f78	SHA-256	HTA file
hxxps://docusign-staples[.]com/api/key hxxps://betterbusinessbureau-sharefile[.]com/api/key	URL	Remote server
aea3ffc86ca8e1f9c4f9f45cf337165c7d0593d4643ed9e489efdf4941a8c495	SHA-256	DLL file
budalixt[.]top/index.html	URL	C&C
11a16f65bc93892eb674e05389f126eb10b8f5502998aa24b5c1984b415f9d18	SHA-256	Similar LNK file
468d7a8c161cb7408037797ea682f4be157be922c5f10a812c6c5932b4553c85	SHA-256	Similar ZIP file

Reference

https://www.sonicwall.com/blog/emotet-campaign-with-bloated-file

https://cloud.google.com/blog/topics/threat-intelligence/rm3-ldr4-ursnif-banking-fraud

The post Notorious Ursnif Banking Trojan Uses Stealthy Memory Execution to Avoid Detection appeared first on Cyble.

Blog – Cyble – ​Read More

By Philippe Laulheret

ClipSP (clipsp.sys) is a Windows driver used to implement client licensing and system policies on Windows 10 and 11 systems.

Cisco Talos researchers have discovered eight vulnerabilities related to clipsp.sys ranging from signature bypass to elevation of privileges and sandbox escape:

• TALOS-2024-1964 (CVE-2024-38184)
• TALOS-2024-1965 (CVE-2024-38185)
• TALOS-2024-1966 (CVE-2024-38186)
• TALOS-2024-1968 (CVE-2024-38062) 
• TALOS-2024-1969 (CVE-2024-38187)
• TALOS-2024-1970 (CVE-2024-38062)
• TALOS-2024-1971 (CVE-2024-38062)
• TALOS-2024-1988 (CVE-2024-38062)

This research project was also presented at both HITCON and Hexacon. A recording of the latter’s presentation is embedded at the end of this article.

What is ClipSp?

ClipSp is a first-party driver on Microsoft Windows 10 and 11 that is responsible for implementing licensing features and system policies, and as such it is one of the main components of the Client Licensing Platform (CLiP). Little is known about this driver; while most Microsoft drivers and DLLs have publicly available debug symbols, in the case of ClipSp, those were removed from Microsoft’s symbol server. Debug symbols provide function names and other related debug information that can be leveraged by security researchers to infer the intent behind the many functions of a binary; their absence hinders that. Surprisingly, the driver is also obfuscated, a very rare occurrence in Microsoft binaries, likely to deter reverse engineering even further. Limited public research exists, much of which either predates our findings or was released in response to our reports. The latter research also shares symbols from an older version of ClipSp, which could be a useful springboard for anyone wanting to research this driver. The most interesting aspect of this software involves implementing features related to licensing Windows applications from the Windows App store and activation services for Windows itself.

 

Deobfuscation

The driver is obfuscated with Warbird, which is Microsoft’s proprietary obfuscator. Luckily, past research comes in handy, and we can adapt to suit our needs. The plan to deobfuscate the driver is to leverage the binary emulation framework Qiling, to emulate the part of the driver responsible for deobfuscating the obfuscated sections, and dump the executable memory range to import it into our favorite reversing tool.

During normal operation, the obfuscation appears as follows:

We can see that a decrypt function is called twice with different parameters, followed by a call to the actual function being deobfuscated and, finally, two calls to re-obfuscate the relevant section.

Using Ida Python, we can track all the references to the decrypt functions (there are actually two distinct functions), and recover their arguments by looking at the instructions that precede the function call where the RCX and RDX registers are being assigned. Per calling conventions, these two registers are the first and second arguments of the function. Then, we can feed this information to our modified Qiling script to emulate the decryption functions and dump the whole deobfuscated binary. Once the driver is deobfuscated, we can start reversing it to understand how Windows communicates with the driver, understand various business logic elements, and look for vulnerabilities.

Driver communication

Usually, drivers either register a device that can be reached from userland or export the functions that are meant to be used by other drivers. In the ClipSp case, things behave slightly differently. The driver exports a “ClipSpInitialize” function that takes a pointer to an array of callback functions that get populated by ClipSp, to then be used by the calling driver to invoke ClipSp functionalities. Grepping for “ClipSpInitialize” throughout the System32 folder shows that the best candidate for using ClipSp is “ntoskrnl.exe”, followed by a handful of filesystem drivers that use a limited amount of ClipSp functions. For the rest of this report, we will focus on how “ntoskrnl” interacts with ClipSp.

Analyzing the cross-references within the Windows’ kernel to ClipSp functions, it becomes clear that, to interact with them, a call to “NtQuerySystemInformation” with the SystemPolicy class is required. Other binaries in the CLiP ecosystem will issue these system calls, while also providing a remote procedure call (RPC) interface to decouple other software from the undocumented API. However, nothing stops us from interacting with the “NtQuerySystemIformation” endpoint directly, which becomes a handy trick to bypass some of the additional checks that are enforced by the intended RPC client library.

Obfuscated structures

Unfortunately for us, looking at how a legitimate binary interacts with the SystemPolicy class, we can see the following (from  wlidsvc!DeviceLicenseFunctions::SignHashWithDeviceKey):

This is another layer of obfuscation that encapsulates the data passed over to the API. The idea here is that a network of binary transformations (also known as a Feistel cipher) is used to encrypt the data with the various operations inline in the code (as seen above). Part of the API call will provide the list of operations that were used, and the kernel will call them directly with the appropriate parameters to decrypt the data. As such, the easier approach to dealing with this is to simply rip out both the encryption code and the associated parameters and re-use them in our own invocation of the API. Copying and pasting the decompiler’s output into Visual Studio is a little tedious but usually works fine. Before returning from the syscall, the resulting data is obfuscated in a similar fashion, and, once again, ripping out the data from a working implementation is the most straightforward way to deal with it. Overall, the data format looks as such:

The inner payload (left) is an array of size-value entries that contain the command number that needs to be executed, followed by the Warbird material used to encrypt the reply from the kernel, and finally command-specific data that depends on which ClipSp function is being invoked.

This data is then encapsulated into a structure that mostly specifies the number of entries there are in the provided array and the whole thing then gets encrypted. The remaining Warbird data in the righ-most part of the diagram is to instruct the kernel how to decrypt the provided data.

Here’s our best guess at the various available commands:

 

Most of them call into ClipSp, but a few (especially in the <100 range) may be solely handled by the Windows kernel.

Sandbox considerations

Microsoft provides a tool to test if a piece of code can be run within a low-privilege context called a Less Privileged Application Container (LPAC) sandbox. Using this with our proof of concept, we can confirm that ClipSp’s APIs are actually reachable from an LPAC context. This is particularly interesting as these application containers are usually used to sandbox high-risk targets, such as parsers and browser rendering processes. As such, any elevation of privilege vulnerabilities we could find would likely double as sandbox escapes as well.

 

Processing licenses

Throughout the reversing process, we observed that the license files handled by ClipSp were quite interesting. They are usually obtained silently from Microsoft when interacting with UWP applications (both coming from the App Store and those installed by default, such as Notepad). They can also be used for other purposes, such as Windows activation, hardware binding, and generally providing cryptographic material for various applications.

At first, license files appear to be opaque blobs of data that are installed via the “SpUpdateLicense” command. This can be invoked following the process described above with the command “_id = 100”. Existing licenses are stored in the Windows registry at the following location:

HKLNSYSTEMCurrentControlSetControl{7746D80F-97E0-4E26-9543-26B41FC22F79}

Only the SYSTEM user can access this registry key. From an elevated prompt, the following command can open regedit as SYSTEM:

PsExec64.exe -s -i regedit

The format for these licenses is mostly undocumented, but looking at how they are being parsed is pretty informative. These licenses are in a tag-length-value (TLV) format, where the list of authorized tags is contained in an array of tuples of the form (tag, internal_index) hardcoded inside ClipSp. Upon parsing, a pointer to each valid TLV entry is stored in an array at the location indicated by the internal_index:

Signature bypass (TALOS-2024-1964)

Licenses are signed by various signing authorities whose public keys are hardcoded in ClipSp. Verification code looks as such:

The “entry_of_type_24” value is a pointer saved during the parsing of the license and points to its signature. The difference between “entry_of_type_24” and “License_data” is pointer arithmetic used to count the number of bytes from the beginning of the license blob up to its signature. 

During the parsing, this looks as such:

If the internal index associated with the entry’s tag is 24, then the processing loop is temporarily exited. A pointer to the signature is saved, and if more data remains, the license processing is resumed.

We can see that this approach is flawed: If there is data after the license’s signature, it will still be parsed but not checked against the signature, effectively enabling an attacker to bypass the signature check of any license as long as they can get one that is already signed with the proper signing authority.

Out-of-bound read vulnerabilities (TALOS-2024-1965,TALOS-2024-1968, TALOS-2024-1969, TALOS-2024-1970, TALOS-2024-1971, TALOS-2024-1988)

We can cross reference where the license structure and its array of pointers to the TLV data is being used, and what we find is many wrapper functions that return either the length/size of a given entry or the data associated with it. In most cases, this is done in a secure fashion, but there are a few entries that make assumptions on the size of the data provided in the license blob, which leads to a handful of out-of-bound read vulnerabilities. An example of such vulnerabilities can be seen in the following screenshots:

These two functions retrieve either the size of the DeviceID field or its content. However, if the data is formatted in such a way that line 11 is reached (i.e., no entry of type 5 in the license provided) then the data field of entry 18 is used to provide both size and value by dereferencing its pointer, without checking if enough data was provided for that. For instance, if we append a DeviceID entry (type 18) at the end of a valid license blob, but make it so its data field is only one byte long, then the “get_DeviceIDSize” function will read one byte out of bound, as it is expecting two bytes of data. Furthermore, any function that calls “get_DeviceID” will receive a pointer that is pointing one byte past the end of the license file and will likely act on wrong information from the “get_DeviceIDSize” function for further out of bound (OOB)-read problems.

Turning an OOB-read into an OOB-write (TALOS-2024-1966)

If we look specifically at the case described above where the DeviceIdSize field can be read out of bound, this creates a particularly interesting situation where the expected size of the DeviceID object can change throughout its lifetime if the data immediately adjacent in memory changes in a meaningful way. The first byte of data after the license blob will also be read as the leading byte of the (unsigned short) value defining the size of the DeviceID. Looking at how these two functions are used in ClipSp, we can see that during the installation of a hardware license, the following happens:

We can see multiple calls to the “get_DeviceIDSize” function, with one providing the size field to a memory allocation routine, while another call is used as a parameter to a “memcpy”. If the size field changes in between the two calls, this may lead to an out-of-bounds write vulnerability.  

Exploiting a vulnerability like this is far from trivial, as one would have to win a race condition between the two fetches while being able to shape the PagedPool heap in such a way that there’s meaningful data located right after the malicious license blob.

Conclusion

As we have just seen, obfuscated code can hide low hanging fruit, trivial memory corruptions, and simple logic bugs. In the case of ClipSp, this issue is even more serious, as this attack vector may lead to sandbox escapes and potentially significant impact to the compromised user.

As such, this is a reminder for security researchers on the value of taking the less traveled path, even if it begins with a bramble of Feistel functions. And for the software engineers and project managers who decide to leverage obfuscation for their projects, this is also a stark reminder that this approach may hinder normal bug finding processes that would detect trivial bugs early on.

 

[Please embed video from: https://www.youtube.com/watch?v=9t0Xt40RZEc  ] 

Cisco Talos Blog – ​Read More