We at Kaspersky recently conducted a study and found that the average person spends $938 a year on 12 subscriptions. This just confirms that in today’s world, being subscribed to numerous services is just as much a part of everyday life as having your smartphone with you at all times.

There are subscriptions for everything: music, movies, fitness, security solutions, and even messaging apps. In this article, we’ll focus on one of the latter — Telegram Premium, a subscription that doubles almost all the messenger’s free-version’s limits. And the coolest thing about it is that you can give it to your friends as a present. If you have a large contact list, Telegram frequently reminds you of this possibility. Of course, scammers are exploiting this feature, sending out fake Telegram Premium gift subscriptions left and right.

So what’s behind these gift subscriptions from cybercriminals — and how can you protect your Telegram account?

How the Telegram gift-subscription scam works

It all starts with an innocent-looking Telegram message from someone in your contact list (actually — an impostor): “You’ve been sent a gift — a Telegram Premium subscription”. Beneath it is a link that, at first glance, seems legitimate. And indeed, it leads to an official-looking Telegram Premium channel. But there’s a catch…

The text you see — https://t.me/premium — actually hides a link to a completely different phishing page. It’s a simple trick. Consider this example: here’s a link to the Kaspersky Daily blog homepage — https://kaspersky.com/blog, but it actually redirects to the homepage of our other blog, Securelist. Scammers use the same principle: they mask their phishing links with seemingly legitimate addresses.

Let’s return to the Telegram gift-subscriptions scam. The phishing page looks like a regular Telegram login page in a browser. However, the scam is betrayed by the dodgy URL: the address starts with the familiar https://t.me, but then has something extra, which wouldn’t be there if were a legitimate page:

If you enter your account details here, consider them stolen. Your user name, password, and possibly your two-factor authentication code will end up in bad guys’ hands. Once you’ve handed over your credentials, the scammers display a congratulatory message and start a 24-hour timer, claiming it’s the activation period for Telegram Premium. This delay is a classic cybercriminal tactic. They’re counting on the user either forgetting about the subscription or believing it’s genuinely on its way. Most likely, the only thing that will happen during these 24 hours is that you’ll permanently lose access to your account.

How else do scammers exploit gift Telegram subscriptions?

Since Telegram Premium launched several years ago, various scam scenarios have emerged. Unsurprisingly, these scams bear similarities to other primitive forms of fraud we frequently discuss on the Kaspersky Daily blog.

For example, cybercriminals might claim to host a free raffle for a three-month Telegram Premium subscription. However, there’s no real drawing of the winning “tickets” — everyone’s a winner; however, the prize isn’t a genuine gift subscription. Victims are directed to click a link and log in to Telegram on a phishing site. And that’s where their accounts get compromised.

Another common tactic involves distributing APK files for supposedly “hacked” Telegram apps bundled with Premium subscriptions. Needless to say, such modified apps are often nothing more than malware in disguise.

Now, you’ll have noticed that the screenshots above are in various languages. The fact is that these scammers operate all over the world, and if this scheme hasn’t reached your region yet, rest assured it surely soon will. Therefore, you should ensure the security of your devices and accounts with reliable protection.

How to protect your Telegram account

To start, we recommend setting up your Telegram security and privacy using our guide. If you’ve already done this, here are some additional tips to help you avoid becoming a victim of these and other scams:

• Remember that there’s no such thing as a free lunch. Before celebrating a sudden gift, double-check if the sender really has good intentions. At the very least, contact them via a different communication channel — call them, use another messenger, or verify in person. As your personal account is at stake, you’d better err on the side of excessive caution.
• Purchase subscriptions only through official channels. Telegram, for example, has a designated bot for buying subscriptions.
• Enable two-factor authentication. This could be your last line of defense in case you fall for a scam. One way to store your 2FA tokens conveniently and securely is in Kaspersky Password Manager.
• Learn more about other ways scammers can steal your Telegram account. There are countless fraudulent schemes — many of which are more sophisticated than they appear.
• Slow down, even if you’re being rushed. Scammers love pressuring victims with timers. When it comes to your digital safety, ignore countdowns and take your time.
• Be cautious about alternative versions of apps. We recommend only using official apps, because unofficial versions are almost always loaded with Trojans.

Kaspersky official blog – ​Read More

In this article, ANY.RUN‘s analyst team will explore a malicious loader known as PSLoramyra. This advanced malware leverages PowerShell, VBS, and BAT scripts to inject malicious payloads into a system, execute them directly in memory, and establish persistent access.  

Classified as a fileless loader, PSLoramyra bypasses traditional detection methods by loading its primary payload entirely into memory, leaving minimal traces on the system. 

PSLoramyra Loader: Technical Analysis 

To see PSLoramyra loader in action, let’s have a look at its sample inside ANY.RUN’s sandbox: 

View analysis 

Initial PowerShell script 

Let’s take a closer look at this loader. The infection chain begins with an initial PowerShell script that contains both the main malicious payload and the scripts required to execute it. The script performs the following steps: 

1. File creation:  

The script generates three files critical to the infection chain: 

1. roox.ps1 

2. roox.bat 

3. roox.vbs 

2. Execution chain: 

1. The roox.vbs script is executed first to initiate the process. 

2. roox.vbs launches the roox.bat script. 

3. roox.bat then runs the roox.ps1 PowerShell script. 

3. Payload execution:  

The roox.ps1 script loads the main malicious payload directly into memory using Reflection.Assembly.Load.

It then leverages RegSvcs.exe to execute the payload. In this case, the payload is the Quasar RAT. 

Establishing Persistence with Task Scheduler 

The PowerShell script establishes persistence by creating a Windows Task Scheduler task that runs roox.vbs every two minutes. Here’s how it operates step by step: 
 

1. Creating the scheduler object: 

The script initializes a Task Scheduler object using the following command: 

New-Object -ComObject Schedule.Service  

It then connects to the Task Scheduler service: $scheduler.Connect() 

2. Defining a new task: 

A new task is created with: $taskDefinition = $scheduler.NewTask(0)  

The task is described, and its execution is enabled: $taskDefinition.Settings.Enabled = $true 

3. Setting the Trigger: 

A trigger is configured to execute the task every two minutes: $trigger.Repetition.Interval = “PT2M”  

4. Configuring the Task Action: 

The action specifies the execution of the roox.vbs script: $action.Path = “C:UsersPublicroox.vbs 

5. Registering the Task: 

Finally, the task is registered in the Task Scheduler, ensuring it runs continuously: $taskFolder.RegisterTaskDefinition() 

Script Creation 

The initial PowerShell script generates multiple scripts and writes them to the disk. This is achieved using the following command: [IO.File]::WriteAllText(“PATH”, CONTENT) 

The content of these scripts is initially stored in variables such as $Content. 

Detailed Script Breakdown 

Roox.vbs script 

This script runs every two minutes and acts as the starting point for executing the other scripts in the malware chain. Essentially, it serves as a link between the Task Scheduler and the subsequent scripts, ensuring the infection chain progresses successfully. 

The roox.vbs script launches the next script in the chain, roox.bat, in a hidden window. This ensures that its execution remains invisible to the user, maintaining the stealth of the infection process. 

1. Error handling: 

The command on error resume next suppresses error messages, allowing the script to continue execution even if exceptions occur. This ensures the script does not fail visibly during the process. 

2. CreateWshShellObj function 

This function creates a COM object named WScript.Shell. The object is used to execute commands and scripts, which are essential for launching the next stage in the infection chain. 

3. GetFilePath function 

This function retrieves the path to the next stage in the chain, specifically pointing to the BAT file roox.bat. 

4. GetVisibilitySetting function 

Configures the visibility settings to ensure that roox.bat runs without displaying a window on the desktop. This stealthy execution minimizes the chances of detection by the user. 

5. RunFile function

Executes a file at the specified path with the defined visibility settings. In this case, it launches roox.bat in hidden mode. 

6. Sequence of calls 

The script executes the required functions in the following order to launch roox.bat: 

• Creates the WScript.Shell object using CreateWshShellObj. 
• Retrieves the path to roox.bat via GetFilePath. 
• Configures the visibility mode to hidden (0) using GetVisibilitySetting. 
• Executes roox.bat in hidden mode through the RunFile function.

ROOX.BAT Script 

This script runs roox.ps1 using PowerShell. It employs the following flags to enhance stealth and bypass security measures: 

• NoProfile: Prevents the loading of user-specific PowerShell profiles 

• WindowStyle Hidden: Hides the PowerShell window during execution, ensuring that the process remains invisible to the user. 

• ExecutionPolicy Bypass: Overrides Windows PowerShell execution policies, allowing scripts to run without restrictions imposed by security configurations. 

ROOX.PS1 Script

The roox.ps1 PowerShell script deobfuscates the main malicious payload, dynamically loads it into memory, and executes it using .NET Reflection and RegSvcs.exe. The script employs simple obfuscation using the # character to make detection more challenging.

The variables $RoXstring_lla and $Mordexstring_ojj store the main malicious payload in the form of HEX strings, with each byte separated by %&% as a means of obfuscation. 

Deobfuscation Process 

The script uses the following commands to convert the obfuscated HEX strings into usable binary code: 

[Byte[]] $NKbb = $Mordexstring_ojj -split '%&%' | ForEach-Object { [byte]([convert]::ToInt32($_, 16)) } 

[Byte[]] $pe = $RoXstring_lla -split '%&%' | ForEach-Object { [byte]([convert]::ToInt32($_, 16)) } 

What these commands do: 

• Split the HEX strings: They split the HEX strings $Mordexstring_ojj and $RoXstring_lla into arrays using %&% as a delimiter. 
• Convert HEX to decimal bytes: Then, each element in the array converts the HEX string into a decimal byte value. 

ForEach-Object { [byte]([convert]::ToInt32($_, 16)) } 

Form byte arrays: This forms a byte array (Byte[]), representing the binary code of the payload. 

Deobfuscate using -replace: 
Obfuscated commands are cleaned by removing # symbols using the -replace command. For example, a string like L####o####a####d is transformed into Load. 

Restore the method name: 
The variable $Fu restores the method name [Reflection.Assembly]::Load, which is used to load a .NET assembly into memory. 

Payload execution in memory: The script dynamically loads the NewPE2.PE type from the .NET assembly and calls its Execute method. The Execute method injects malicious code into a legitimate process, such as aspnet_compiler.exe. In this case, the target process is RegSvcs.exe. 

The initial variable $RoXstring_lla contains the injector for the .NET assembly NewPE2, which is responsible for loading the main payload into the process.

Within this assembly, the script locates the type NewPE2.PE and executes the Execute method. The latter is provided with parameters: the path and the malicious .NET assembly itself. 

Use the following query to search for more samples and threat data in TI Lookup:

Conclusion

PSLoramyra is a sophisticated fileless loader. It leverages PowerShell, VBS, and BAT scripts to inject and execute malicious payloads directly in memory, evading traditional detection methods. Its infection chain begins with an initial PowerShell script that generates essential files and establishes persistence through Windows Task Scheduler. The malware’s stealthy execution and minimal system footprint make it a serious threat.

About ANY.RUN  

ANY.RUN helps more than 500,000 cybersecurity professionals worldwide. Our interactive sandbox simplifies malware analysis of threats that target both Windows and Linux systems. Our threat intelligence products, TI Lookup, YARA Search and Feeds, help you find IOCs or files to learn more about the threats and respond to incidents faster.  

With ANY.RUN you can: 

• Detect malware in seconds
• Interact with samples in real time
• Save time and money on sandbox setup and maintenance
• Record and study all aspects of malware behavior
• Collaborate with your team 
• Scale as you need

Explore all Black Friday 2024 offers →

Indicators of Compromise (IOCs)

Hashes 

ac05a1ec83c7c36f77dec929781dd2dae7151e9ce00f0535f67fcdb92c4f81d9 

9018a2f6018b6948fc134490c3fb93c945f10d89652db7d8491a98790d001c1e 

d50cfca93637af25dc6720ebf40d54eec874004776b6bc385d544561748c2ffc 

Ef894d940115b4382997954bf79c1c8272b24ee479efc93d1b0b649133a457cb 

Files 

C:UsersPublicroox.vbs 

C:UsersPublicroox.bat 

C:UsersPublicroox.ps1 

Domain 

Ronymahmoud[.]casacam[.]net 

IP 

3[.]145[.]156[.]44 

The post PSLoramyra: Technical Analysis of Fileless Malware Loader appeared first on ANY.RUN’s Cybersecurity Blog.

ANY.RUN’s Cybersecurity Blog – ​Read More

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