Warning: Fileless attacks are on the rise

Fileless attacks are on the rise!

Ever heard of fileless attacks? This is malicious code gets a foothold on your server. Not through a certain file or a document, but by infiltrating the server RAM. Thus, exploiting various processes and vulnerabilities of the server software. They can do this via vulnerable web applications, specially formed requests, and so on.

The idea behind fileless attack

The harm that a fileless attack inflicts leaves no trace since its malware does not write any files to the hard drive. Instead, it performs all malicious activities directly in RAM. After the system reboots, the malicious code disappears – but the damage has already been done to your server. This type of threat is commonly referred to as an Advanced Volatile Threat (AVT).

Some types of malicious code harm system files, some set up malicious code for other types of attacks, and others open entry points for hackers to use other server’s vulnerabilities. Both users and security solutions, like McAfee Endpoint Security, Virsec Security Platform, and others, are not tuned for Fileless attacks. Thus, making them hard to detect.

Fileless Malware Found On Various Operating Systems

On Windows servers, hackers actively use the pre-installed system Powershell to download and run malicious code. Or they can also use BAT and VBS scripts. These techniques are now widespread since you can execute them in frameworks like Powershell Empire, Powersploit, and Metasploit Framework.

As for Linux, most installed distributions like CentOS, Ubuntu, and Debian, have pre-installed software. This usually has programming languages interpreters: Python, Perl, and С compiler – a bad practice of installing an operating system on servers. Lots of hosting servers also have PHP installed because of its huge popularity. So Fileless attacks use these interpreters.

How Fileless Malware Survives on Linux

On Linux, the easiest way to run malicious code in RAM by way of fileless malware is to use shared memory. Hence, a block of RAM shared and pre-mounted in the file system. By placing an executable file in /dev/shm or/run/shm, it’s possible to run the file directly in RAM. Remember that these directories are nothing but shared memory.

However, the content of these directories can be viewed with the ls command, which works for any other directory. Moreover, these directories are usually mounted with the noexec flag and only root can run programs in them. Therefore, more intricate types of fileless malware use, for example, the memfd_create system call (in case of the C programming language).

Interpreted languages, such as Perl and Python, which are widely used in web hosting, also offer the ability to use syscall(). PHP, which is even more popular, does not have built-in techniques to use syscall. However, there are old tricks that allow using required system calls even in PHP.

Fileless Attacks Are Increasing

Fileless attacks increase

According to research carried out by Ponemon Institute in 2018, we should expect fileless attacks to grow and make up 35% of all cyberattacks worldwide. Consequently, there will also be a decrease of regular file-based attacks.

Fileless vs file-based attacks

Fileless attacks are particularly dangerous in the corporate world since. Because Fileless malware becomes especially effective after installing in the RAM of servers active 24/7, 365 days a year. So Fileless attacks can hit any organization – like the Democratic National Committee in the US in mid-2016 for example. A hacker known as Guccifer 2.0 inserted a piece of Fileless malware into the Committee’s system and then gained access to 19,252 emails and 8,034 attachments. The document of the District Court for the District of Columbia states that Powershell scripts were used to hack the Microsoft Exchange Server of the Committee.

This intrusion resulted in the publication of a series of revelations that ended up hindering Hillary Clinton, Donald Trump’s then rival.

How to protect against Fileless attacks

Cybersecurity experts recommend the following measures to withstand the threat of fileless malware intrusion:

  1. A company that wants to protect its corporate cyber security has to be cyber-resilient and therefore stay informed about new kind of attacks.
  2. Avoid scripting languages like Powershell, because fileless malware actively exploits them. You can either delete Powershell or configure the system so that an attacker can’t exploit it.
  3. Use adapted solutions to detect malicious code – not just on the file system, but also in the RAM.
  4. Beware of Macros – they’re the most common tools on any computer and a possible entry point for fileless malware. As with scripting languages, companies don’t necessarily need to give up on all kinds of Macros. But they do need to be responsible when using them.

Fileless Attack Prevention Advice – From the Experts

Reputable sources of protection against fileless attacks stress that you need to “Keep your software up to date. As inconvenient as they can be, software updates are usually done to patch critical security vulnerabilities.” It’s one of the best practices for fileless malware protection.

As far as Microsoft products are concerned, Comparitech tell us “How to stop fileless malware”: “The main defense against any type of malware is to keep your software up to date. As Microsoft has been very active in taking steps to block the exploitation of PowerShell and WMI, installing any updates from Microsoft should be a priority.”

Ilia Kolochenko, CEO, Founder, High-Tech Bridge, speaks about the vulnerability of not keeping web applications up to date:

“It’s a very colorful, albeit very sad, example how a vulnerability in a web application can lead to disastrous consequences for an entire company, its customer base and beyond. Today, almost any critical data is handled and processed by web applications, but cybersecurity teams still seriously underestimate the risks related to application security.

Most companies don’t even have an up2date application inventory. Without knowing your assets, you won’t be able to protect them. Many global companies still rely on obsolete automated solutions and tools for their application security, while cybercriminals are already using machine-learning in their attacks when targeting and profiling the victims.”

Our cybersecurity experts at Plesk also advocate the importance of timely and regular installation of updates. Whether on your operating system, hosting server software, web applications, or CMS plugins. Right now, it’s the best way to protect against fileless attacks. Have a look at our Change Log for the latest information and released Plesk updates, and their installation procedure.

All You Need to Know about the New WordPress Toolkit 3.5 [ VIDEO ]

Plesk WordPress Toolkit 3.5

Your needs come first so rest assured that we’re constantly evolving Plesk to bring you more value. Hence, the release of WordPress Toolkit 3.5, introducing an assortment of new security measures, a reimagined installation experience and more. Read on for a detailed overview of the updates you wanted, a WordPress Toolkit tour, plus WordPress Toolkit 3.6 spoilers.

Quick Tour of the updated WordPress Toolkit

Our pal Joe Casabona was one of the first to take the new WordPress Toolkit 3.5 for a spin. Here’s him demonstrating how easy it is to install and secure your WordPress, update multiple sites, clone and create a staging environment. All in just over 7 minutes!

New WordPress Toolkit Security Measures

New Plesk WordPress Toolkit 3.5 Screenshot 1-new-security-measures

First, you’ll likely see this notification pop up or find your previously secure instances suddenly marked as insecure. But don’t be alarmed – this just means you need to review and update the security status of your WordPress instances. Why? Because WordPress Toolkit 3.5 introduces 8 new security measures.

New Plesk WordPress Toolkit 3.5 Screenshot 2 - new security measures list

1.    New Hotlink Protection

Preventing other websites from displaying, linking or embedding your images (hotlinking), as this quickly drains your bandwidth and can make your site unavailable.

2.    Disable unused scripting languages

This security measure removes support for the scripting languages WordPress doesn’t use, like Python and Perl. Thus, blocking their related vulnerabilities. Available if you have the corresponding Hosting Settings management permission.

3.    New Bot Protection

Blocks bots that overload your site with unwanted requests, causing resource overuse. Note that you may want to temporarily disable this if you also use a service that scans your site for vulnerabilities, since it may also use bots.

4.    Disabled file editing in WP Dashboard

This measure prevents you from editing plugin and theme file sources directly in the WordPress interface. This is an extra protection layer for the WordPress instance in case an admin account is compromised so no malicious executable code gets into plugins or themes.

5.    Block access to sensitive files

Now you can choose to block files like wp-config.bak and wp-config.php.swp, from public access as they contain sensitive information, like connection credentials. Thus, also preventing exposure of files with info used to determine your WordPress instance. Also included are files like logs, shell scripts and other executables that may exist on your WordPress instance and whose security can be compromised.

6.    Block author scans / user ID phishing

These scans find registered usernames, especially WordPress admin, and brute-force attack your site’s login page. The above block prevents this, but note that depending on your site’s permalink configuration, you may also be preventing visitors from accessing pages that list all articles by a certain author.

7.    Block access to .htaccess and .htpasswd

Attackers who gain access to .htaccess and .htpasswd files can exploit your site to a variety of breaches. These files aren’t usually accessible by default, but sometimes they might be. This is where this security measure steps in.

8.    Disable PHP execution in cache directories

If a compromised PHP file ends up in one of the cache directories of your site, executing it can lead to compromising the whole site. So this measure disables execution of PHP files in cache directories to prevent such exploits. However, certain plugins and themes may ignore WordPress Security recommendations and store valid PHP executables in their cache anyway. So you can disable this security feature for them to work, or find a more secure alternative, as recommended.

You’re in Control of Security Updates

You should be able to supervise any website-affecting changes so WordPress Toolkit won’t automatically apply these new security measures on existing installations. So upon opening your list of WordPress instances after the WordPress Toolkit 3.5 update, you’ll see a one-time notification about this.

On that note, you’ll now see that two existing security measures are now less restrictive. First, the “Security of the wp-includes directory” checker now excludes the wp-tinymce.php file to avoid potential issues with Gutenberg and other editing  plugins. Second, the “Security of the wp-content directory” measure now prevents the execution of PHP files only in the wp-content/uploads directory.

New Plesk WordPress Toolkit 3.5 Screenshot 3 - control security updates

These checkers will be reapplied automatically for convenience and do not reduce WordPress security in any noticeable way.

New WordPress Toolkit 3.5 Installation Experience

WordPress Toolkit previously offered two installation options: Quick and Custom. Both had unfortunate shortcomings. ‘Quick’ didn’t ask you questions, but also didn’t give info on the parameters to use when installing WordPress. ‘Custom’ gave you control and displayed everything, but you had to fill out the form.

New WordPress Toolkit installation experience

Now users can make an informed choice whether to confirm defaults and install WordPress quick, or take time to change the options they want. With the new, unified WordPress installation, you can still install WordPress in one click, but you’ll always know how it’s happening. Meanwhile, you can change all relevant installation parameters when necessary.

Bonus: You now have to enable automatic updates of plugins and themes within a more streamlined form, without Search Engine Visibility and Debug Mode.

WordPress Toolkit - Automatic update settings

The final change to the WordPress installation process is the ability to install on any domain from any accessible subscription. This is available anytime you click WordPress in the left navigation panel, even if you’re a reseller or server admin. One small step for WordPress Toolkit, one giant leap for adminkind.

New Plesk WordPress Toolkit 3.5 Screenshot 6 - install on any domain from any accessible subscription

WordPress Classic Plugin anyone?

If you’re not yet ready to use Gutenberg, you have a new ‘WordPress Classic’ plugin set. It also has a sibling ‘WordPress Classic with Jetpack’. However, note that we don’t plan to add immediate support for ClassicPress.

WordPress Classic plugin

Updates to CLI

We updated the CLI command for the new WordPress installation. Specifically adding -auto-updates, -plugins-auto-updates, and -themes-auto-updates to the plesk ext wp-toolkit install command. And plesk ext wp-toolkit –clear-wpt-cache to clean WordPress Toolkit cache and handle issues with invalid cache data like corrupted WordPress distributive lists, or broken lists of languages and versions.

WordPress Toolkit 3.6 Spoilers

The Plesk team fixed a record 43 issues reported by customers and over 140 bugs reported overall. Moving forward, WordPress Toolkit 3.6 will lay foundations for the upcoming release of Remote Management for WordPress Toolkit. Plus, we’re continuing the switch to the new UI, this time redesigning the Clone and Sync procedures along with more relevant user-requested improvements. We’re also busy improving our internal process so we can deliver more high-quality stuff in less time, so stay tuned!