Most malware works by installing hostile code files on a target system or adding code to existing files. It can be detected, at least in principle, by spotting those files. The past few years have seen the growth of a sneakier kind of malware. It doesn't use file-based code but instead runs in memory.

Sometimes it's called zero-footprint software, though this isn't strictly accurate; malware has to have some effect in order to be malware. But it's significantly harder to detect than code based in files. This kind of malware has been around for decades, but it's seen serious growth in the past few years. It represents a shift in tactics to avoid detection. New cybersecurity protection methods are needed to prevent it from doing harm.

The term "fileless" applies in several senses, and sometimes the term is overused as a buzzword. The most common case is malware running only in memory, but it's also applied to firmware rootkits, malicious USB devices, and malware injected into the Windows registry.

Tech Republic gives a taxonomy with three types of "fileless" attacks:

• Type 1: True fileless malware. The payload resides only in memory or firmware.
• Type 2: Uses files indirectly. Common cases include feeding commands to a shell or other system service and running code from a remote file.
• Type 3: Actually file-based, but persistent in memory after loading. Calling these "fileless" is a stretch of the term.

Server-side malware typically starts with a POST parameter that exploits a vulnerability. It's most often a Type 2 attack, running a payload from a remote server. Because it doesn't have to write to the file system, file-oriented defenses won't stop it from running. With this approach, the remote code is transient in memory, but it can have permanent effects.

While the concept of memory-resident malware is nothing new, it wasn't a major threat until 2016 or 2017. Kaspersky Lab discovered widespread fileless attacks in February 2017. Governments, banks, and telecommunication businesses were the most frequent targets.

A 2017 report from the Ponemon Institute found that 28% of all online attacks that year were fileless, and the success rate was far higher for them than for file-based malware. Since then the growth rate has been explosive. Fileless malware saw a 265% increase in the first half of 2019, compared with a year before.

When one approach becomes less successful, criminals try another. Anti-malware software blocked many attempts to deposit hostile code files on target systems, so the attackers increased their use of methods that don't require doing that.

The escape of the EternalBlue exploit from the NSA marked a significant turning point. It exploits a vulnerability in older versions of a Microsoft messaging protocol. EternalBlue in itself is fileless, but it's often used in conjunction with file-based ransomware and other malware.

Fileless attacks have the disadvantage, from the attacker's viewpoint, of being less persistent. Some last only as long as an HTTP request and response; most can be flushed by rebooting the computer. The new tactic is to infect the target repeatedly, rather than relying on it to stay there. As long as the attack isn't detected, the same technique will keep working. It can run in intermittent bursts to decrease the chances of detection.

The news media's focus has been mostly on attacks on personal computers, usually on the Windows PowerShell and Registry. Fileless attacks on servers are less exciting for the average computer user, but they're a serious cybersecurity threat to IT departments. A successful attack on a Web server or database is a more serious concern than one on a workstation. A lack of publicity doesn't mean a lack of risk. Small businesses are frequent targets because criminals think they're less well protected.

The most common mode for a fileless attack on a Web server is remote code execution (RCE). The first step exploits a server vulnerability that lets a malicious request execute code on the server. Given the wide use of PHP server software, the attacks most often inject PHP code.

A very naive scenario would be a Web application that accepts PHP in a parameter and blindly runs it. Hopefully, no production sites do this, but that doesn't mean they're safe. Buffer overflows or errors in parsing the parameter may enable code injection.

For example, let's say a vulnerability gets a server to execute this code from a parameter:

The parameter z0 contains arbitrary PHP code. For instance, it might contain:

The code in the remote file runs on the server without ever being stored as a local file. Anti-malware software can't find or remove anything on the disk.

The attack can run repeatedly, as long as the vulnerability exists. The people behind it can attack in bursts during the night and then stay quiet for hours, leaving security analysts with nothing to observe. A web application firewall provides a defense against these attacks.

Another approach subverts shell commands or other scripting operations. A parameter might contain a filename that the application inserts into a shell command. Let's say it accepts the parameter "information.dat" to build the command:

The shell performs a presumably legitimate update operation. But suppose a malicious client sends the value "information.dat; rm -rf *"
If the application doesn't take precautions, the command becomes:

All the files in the current directory are gone. This is a simple example; the commands could initiate hard-to-spot activities, such as copying confidential data to a remote server.

Website protection against these attacks begins with secure applications. When you use an application from a vendor, install all security patches promptly. Criminals learn about vulnerabilities and target unpatched Web applications.

Your own applications should filter all inputs so that the parser doesn't receive intentionally malformed ones. SQL injection and buffer overflow attacks similarly use invalid inputs to trick the application into misinterpreting them.

Don't allow executable code in request parameters or cookies. Requests should give information to server-side code. Getting code in parameters may make the application more flexible, but the risk isn't acceptable.

Developers make mistakes, though. In spite of their best efforts, they can leave vulnerabilities in the code. Defense in depth requires stopping malicious packets before they reach the application.

If your anti-malware tools look only for suspicious files, they won't give you enough protection. You need a web application firewall (WAF) that will shield your applications from malicious requests. Quttera's WAF gives you this kind of cybersecurity defense, spotting suspicious requests and keeping them from reaching the server. The Quttera WAF is part of the ThreatSign platform, which guards against attacks and spots any sign of a breach. Sign up today and enjoy the feeling of increased confidence that your site will run securely.