Linux malware: beginner’s guide to avoiding detection

All too often, Linux users indulge in the fantasy that using Linux makes you immune to malware. The fact is, the safety of Linux as a desktop comes largely thanks to its unpopularity, meaning malware devs mostly target Windows (and to a lesser extent, MacOS). Antimalware tech for Linux lacks important features and even basic malware can easily avoid it. If you’re a normal person browsing the web with Linux, you don’t have anything to worry about. But for servers running large apps, Linux malware always looms as a threat.

In this article, we discuss how malware hides in Linux systems, how it blends in with other running threads and processes, and how it avoids detection by malware analysis tools. Finally, we’ll offer a few tips to help you continue your malware analysis learning journey.

Let’s start hacking!

Hiding files

Let’s start with the oldest trick: dotfiles. If you know how to use the Linux commandline, you likely already know that putting a dot at the beginning of a files name makes the file “hidden”. In practice, this means that the file won’t show up in your file explorer, or when you list the files in a directory by typing the ls command.

Fun fact: dotfiles were an accident, according to legendary Unix developer Rob Pike (source: a lesson in shortcuts).

It’s better than nothing, but easy to defeat. Users can view dotfiles by simply using the -a option, like so:

➜  dotfiles ls
notes.txt
password.hash

➜  dotfiles ls -a
.malware.exec
notes.txt
password.hash

Of course, a full system scan would still find us. Antivirus tools work by scanning all of the files in the filesystem and comparing them to hashes of known malware samples. So while it’s still better to put a file in /tmp than in /root for obvious reasons, it’s still not enough.

An even better idea is to hide the malware inside of an existing, normal file. By far, the standard targets for this tactic are crontabs and .bashrc. You can also hide inside of shared object files, or really anything that your system regularly executes. Adware, for example, usually replaces Chrome or Firefox with a version of the same that has a malicious extension added.

Hiding process

Hiding processes is more complex than hiding files. It’s possible for antivirus to detect known malware by comparing in-memory data to known malware hashes, but in practice this is nearly unheard of. The biggest thing you can do to hide your processes is to give them good names.

If someone types the top command to see what’s eating up their system’s RAM and they see a process named ./monero_miner.sh they will know what’s up and start removing the malware from their system. Use the command ps aux to see what processes are already running, so you can give your process a similar name. For example, naming your process after cron or a browser or a web server will help you avoid detection.

Furthermore, avoid eating up too many resources. Malware that uses up 100% CPU won’t go long without detection. Instead, use up a modest amount, in short bursts. That way, admins can’t log in and debug the problem. By the time they’ve handled a report about excess CPU usage, the malware has already stopped!

To top things off, here are some other “evil” tips for how malware processes hide:

• Don’t connect to a known malicious IP. “Sneak” out of the box using a VPN or proxy.
• Turn the process off when human users connect via SSH or a hardware terminal.
• Write custom malware. Avoid old viruses that antivirus tools can easily detect.

Virtual machine awareness

When hacking pros think a file might be malware, they usually run it in a virtual machine and see what happens. Most malware will connect to a command and control server. Or perform some other risky action. To avoid this sort of detection, modern malware deploys checks to see if it’s running inside of a virtual machine.

If the malware detects that it’s in a VM, it simply does nothing.

So how do you detect whether you’re running inside of a VM?

The lazy way is to use the dmidecode command, which tells you what hardware a system runs on. Since there are only a few popular VM platforms out there, you can check if any of them show up when you run the command dmidecode -s system-manufacturer.

You can find a more complete list of the outputs of this command for all kinds of systems here: https://ostechnix.com/check-linux-system-physical-virtual-machine/.

Beware that now days, many cloud providers provide fake responses that obscure the underlying hardware. For example, if I run this command on my DigitalOcean server, I see this.

dmidecode -s system-manufacturer
DigitalOcean

Of course, malware analysts have thought of this too. New malware analysis tools deal with the dmidecode trick by telling VMs to lie about their hardware. So if you run this command within a malware analysis virtual environment, it will say you’re on a Dell machine.

This is only one of the most basic ways of detecting a VM. The whole topic of VM awareness is an endless cat and mouse game. For a fun example of this rabbithole, read this blog post from MalwareBytes: https://www.malwarebytes.com/blog/news/2014/02/a-look-at-malware-with-virtual-machine-detection.

Learn more about hiding Linux malware

Malware is a big field with a lot to study. It’s like learning web dev, in that decades of history shaped the tech, and it doesn’t make a lot of sense without learning a bit of the background. If you like complex tech with rich lore, you’ll enjoy malware analysis.

But learning about malware is not as easy as learning pentesting, compliance analysis, and other more common security roles.

• Lainchan’s malware dev Q&A: https://lainchan.org/sec/res/14192.html
• Begin learning about malware analysis: https://www.sans.org/blog/how-you-can-start-learning-malware-analysis/

Another fun resource is 13channel’s CTF challenges. They host challenges specifically focused on malware development and analysis. You can find all of their challenges here: http://13channel.crabdance.com/ctf/.

Browse through the threads and pick whichever challenges appeal to you the most. Here’s an example of a beginner-friendly one that still hasn’t gotten solved (yet, as of January, 2024):

One final beginner’s resource I want to show you is a classic: HackThisSite‘s app challenges. Although new, fancier CTFs exist, this old site is great for newbies, as the tasks are pretty easy. Once you’re done with them, you should move on to a harder platform like HackTheBox.

Besides the fun factor, CTFs look good on your resume, a big boon when trying to get your first cybersecurity job.

Note on Linux malware ethics and legality

Make sure to check that malware dev is legal in your country or region before releasing any open source proofs of concepts. Furthermore, acquire consent from any targets before doing any hacking, including putting malware on their system. Ethical malware development means adding to the scientific knowledge of computer security, and the real safety of people’s machines, as well as following laws and norms about privacy.