The Linux Mint Backdoor: How Bad Was It?

It was worse than thought, but a lot better than it could have been.

This past Saturday, February 20, it was discovered that one of the most popular Linux desktop distributions had its installation image backdoored. The links on Linux Mint’s homepage, that pointed to installation disk images, were replaced by links to a malicious site. This malicious site hosted copies of the installation disk that contained a backdoor for a simple but effective DoS bot. Linux users looking to install a new operating system were installing this malicious code to their machines.

Compromise Timeline

Stories and links flooded in through social media about the backdoor, but the first notice appears to be from a user on the Linux Mint user forums at 6:40 p.m. UTC on February 20. By 1:44 a.m. UTC on February 21, the Linux Mint team confirmed the attack and was working to resolve the issue.

The comments on the Mint blog show that the Mint team faced challenges in removing the attacker and ultimately shut down the entire Mint website to remove the risk of further infection.

While the transparency provided by Linux Mint is great to see, it doesn’t answer the question of exactly what time traffic began redirecting to the malicious site. A backdoored operating system can pose an extremely large risk by giving complete control of the impacted system to an attacker. This makes establishing an accurate timeline of events an important aspect when understanding and evaluating the risk. It provides a clear window of time for users to assess if their machines may be compromised.

Through the data collected by Level 3 Threat Research Labs, we can confirm the impact was actually worse than what has been reported by other sources to date. The traffic shifted to multiple different malicious hosts three separate times between February 19 and 21:


The final end time on the 21st is an estimate since many security researchers were attempting to access the malicious URLs directly during this time period causing a less clear cut off in traffic. However, it coincides with the discussion occurring on the Linux Mint blog where Clement Lefebvre of the Linux Mint team stated he disabled the website entirely in response to a comment from a user after 3:02 a.m. GMT.

The entire trend of traffic for each malicious IP can be seen in the following time series graph:


During the impacted time period, hundreds of downloads took place, successfully delivering the attacker’s backdoored installation image to Mint users globally.

Backdoor Analysis

The Linux Mint team’s statement indicates that only a single edition of its software was believed to be backdoored: Linux Mint 17.3 Cinnamon. Level 3 Threat Research Labs obtained and analyzed the backdoored disk image, including comparing it to a known good image in order to understand what malicious items had been placed on the installation image. Fortunately, the backdoor was not very sophisticated and very little was done to mask its existence or functionality. This is a much better outcome than could have occurred with a more sophisticated attacker.

The attacker began work on building the image on February 17 and completed it on February 19. The malicious installation image contained more than 1,500 additional items compared with the known good image, largely due to the installation of non-backdoored development and build packages. These packages were installed by the attacker to compile an IRC based DoS bot. The bot code used was functionally an exact copy of the Kaiten bot code, a very old and well-documented bot dating back to 2001.

The bot source code was left on the backdoored disk image in /var/lib/ and the compiled bot binary was installed in /var/lib/apt-cache. These indicators, along with others listed at the end of the article, provide an indication that a system has installed this compromised disk image.

In order to persist the bot through reboots two different cron jobs were installed in /etc/cron.hourly/ and /var/spool/cron/crontabs/root.


etc_cron hourly_man



Each cron entry runs /var/lib/man, a simple perl script which executes the bot if it is not currently running on the system:


These few files work together to ensure the bot is always running and ready to participate in DoS attacks against new victims.


The bot code installed is known as Kaiten, which contains a small number of settings that are expected to be customized by the installer. Our attacker modified the code accordingly, and set the botnet to operate with the following attributes:


The five servers specified include a duplicate of along with three other hostnames:,, and

Level 3’s passive DNS data for the time period of the attack includes DNS lookups for the host, pointing to which was one of the same hosts serving the backdoored installer. The other hostnames saw no DNS activity because the other domains were not registered at the time of the traffic rerouting. The other domains have since been registered, most likely by security researchers or malicious actors.

IRC botnets such as Kaiten have waned in popularity over the last 15 years, but despite their age and being surpassed by more advanced botnet designs, they still function today. This particular botnet is focused on DoS attacks, which can be seen by the command structure including methods for a variety of basic volumetric TCP and UDP attack types.

As with many bots, this code includes the ability to download arbitrary files and execute shell commands on the infected host. In the case of this bot, the User Agent is hardcoded to the very old 4.75 release of Mozilla released in September 2000.

Recommendations and Conclusions

Most open source operating system images take care to provide their users with hashes representing the file being downloaded. This is primarily done to check for file corruption, however, validation for security purposes is clearly a useful step to take as well.

In the case of this image, multiple MD5 hashes were also included inside the disk image, which would have alerted users to the image being modified, if verified through trusted third party sites. The attacker was aware of this and took the time to create a new version of this file, but did not complete the task by overwriting the original.

The Linux Mint project should consider not only including hashes, but also making the verification of cryptographically signed images easier to verify. Since the attacker, in this instance, had access to the image and the website, and the hash was changed, had private keys been used for cryptographically signing the image and been stored off their webserver, a user would have then been able to verify both the MD5 and SHA256 sums did not match.

This compromise should remind security professionals that knowledge of a bot, exploit, or attack vector does not mean it is eradicated. Just like a human disease, when weaknesses present themselves the well-known can return and still be dangerous. So even with these basic recommendations in place, every network should be monitoring its outbound traffic to look for anomalies and interactions with unknown hosts. These best practices used together would have caught and allowed for appropriate response to the risk outlined in this article.


Addendum: IOCs

HTTP Headers:
User-Agent: Mozilla/4.75 [en] (X11; U; Linux 2.2.16-3 i686)




The following two tabs change content below.
The Level 3 Threat Research Labs proactively analyzes the global threat landscape and correlates information across internal and external sources to help protect Level 3 customers and the public Internet.

Latest posts by Level 3 Threat Research Labs (see all)

Leave a Reply

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload the CAPTCHA.