delete extra spaces

This commit is contained in:
Beth Levin
2019-04-02 12:41:49 -07:00
parent d1e07e4e4b
commit a52ff25166

View File

@ -17,7 +17,7 @@ search.appverid: met150
# Fileless threats
What exactly is a fileless threat? The term "fileless" suggests that a threat that does not come in a file, such as a backdoor that lives only in the memory of a machine. However, there's no generally accepted definition. The terms is used broadly; it's also used to describe malware families that do rely on files in order to operate.
What exactly is a fileless threat? The term "fileless" suggests that a threat that does not come in a file, such as a backdoor that lives only in the memory of a machine. However, there's no generally accepted definition. The terms is used broadly; it's also used to describe malware families that do rely on files in order to operate.
Given that attacks involve [several stages](https://attack.mitre.org/wiki/ATT&CK_Matrix) for functionalities like execution, persistence, information theft, lateral movement, communication with command-and-control, etc., some parts of the attack chain may be fileless, while others may involve the filesystem in some form or another.
@ -26,13 +26,13 @@ To shed light on this loaded term, we grouped fileless threats into different ca
![Comprehensive diagram of fileless malware](images/fileless-malware.png)<br>
*Figure 1. Comprehensive diagram of fileless malware*
We can classify fileless threats by their entry point, which indicates how fileless malware can arrive on a machine: via an exploit; through compromised hardware; or via regular execution of applications and scripts.
We can classify fileless threats by their entry point, which indicates how fileless malware can arrive on a machine: via an exploit; through compromised hardware; or via regular execution of applications and scripts.
Next, we can list the form of entry point: for example, exploits can be based on files or network data; PCI peripherals are a type of hardware vector; and scripts and executables are sub-categories of the execution vector.
Finally, we can classify the host of the infection: for example, a Flash application that may contain an exploit; a simple executable; a malicious firmware from a hardware device; or an infected MBR, which could bootstrap the execution of a malware before the operating system even loads.
This helps us divide and categorize the various kinds of fileless threats. Clearly, the categories are not all the same: some are more dangerous but also more difficult to implement, while others are more commonly used despite (or precisely because of) not being very advanced.
This helps us divide and categorize the various kinds of fileless threats. Clearly, the categories are not all the same: some are more dangerous but also more difficult to implement, while others are more commonly used despite (or precisely because of) not being very advanced.
From this categorization, we can glean three big types of fileless threats based on how much fingerprint they may leave on infected machines.
@ -40,7 +40,7 @@ From this categorization, we can glean three big types of fileless threats based
A completely fileless malware can be considered one that never requires writing a file on the disk. How would such malware infect a machine in the first place? An example scenario could be a target machine receiving malicious network packets that exploit the EternalBlue vulnerability, leading to the installation of the DoublePulsar backdoor, which ends up residing only in the kernel memory. In this case, there is no file or any data written on a file.
Another scenario could involve compromised devices, where malicious code could be hiding in device firmware (such as a BIOS), a USB peripheral (like the BadUSB attack), or even in the firmware of a network card. All these examples do not require a file on the disk in order to run and can theoretically live only in memory, surviving even reboots, disk reformats, and OS reinstalls.
Another scenario could involve compromised devices, where malicious code could be hiding in device firmware (such as a BIOS), a USB peripheral (like the BadUSB attack), or even in the firmware of a network card. All these examples do not require a file on the disk in order to run and can theoretically live only in memory, surviving even reboots, disk reformats, and OS reinstalls.
Infections of this type can be extra difficult to detect and remediate. Antivirus products usually dont have the capability to access firmware for inspection; even if they did, it would be extremely challenging to detect and remediate threats at this level. Because this type of fileless malware requires high levels of sophistication and often depend on particular hardware or software configuration, its not an attack vector that can be exploited easily and reliably. For this reason, while extremely dangerous, threats of this type tend to be very uncommon and not practical for most attacks.
@ -69,7 +69,7 @@ Having described the broad categories, we can now dig into the details and provi
**File-based** (Type III: executable, Flash, Java, documents): An initial file may exploit the operating system, the browser, the Java engine, the Flash engine, etc. in order to execute a shellcode and deliver a payload in memory. While the payload is fileless, the initial entry vector is a file.
**Network-based** (Type I): A network communication that takes advantage of a vulnerability in the target machine can achieve code execution in the context of an application or the kernel. An example is WannaCry, which exploits a previously fixed vulnerability in the SMB protocol to deliver a backdoor within the kernel memory.
**Network-based** (Type I): A network communication that takes advantage of a vulnerability in the target machine can achieve code execution in the context of an application or the kernel. An example is WannaCry, which exploits a previously fixed vulnerability in the SMB protocol to deliver a backdoor within the kernel memory.
### Hardware
@ -77,9 +77,9 @@ Having described the broad categories, we can now dig into the details and provi
**CPU-based** (Type I): Modern CPUs are extremely complex and may include subsystems running firmware for management purposes. Such firmware may be vulnerable to hijacking and allow the execution of malicious code that would hence operate from within the CPU. In December 2017, two researchers reported a vulnerability that can allow attackers to execute code inside the [Management Engine (ME)](https://en.wikipedia.org/wiki/Intel_Management_Engine) present in any modern CPU from Intel. Meanwhile, the attacker group PLATINUM has been observed to have the capability to use Intel's [Active Management Technology (AMT)](https://en.wikipedia.org/wiki/Intel_Active_Management_Technology) to perform [invisible network communications](https://cloudblogs.microsoft.com/microsoftsecure/2017/06/07/platinum-continues-to-evolve-find-ways-to-maintain-invisibility/) bypassing the installed operating system. ME and AMT are essentially autonomous micro-computers that live inside the CPU and that operate at a very low level. Because these technologies purpose is to provide remote manageability, they have direct access to hardware, are independent of the operating system, and can run even if the computer is turned off. Besides being vulnerable at the firmware level, CPUs could be manufactured with backdoors inserted directly in the hardware circuitry. This attack has been [researched and proved possible](https://www.emsec.rub.de/media/crypto/veroeffentlichungen/2015/03/19/beckerStealthyExtended.pdf) in the past. Just recently it has been reported that certain models of x86 processors contain a secondary embedded RISC-like CPU core that can [effectively provide a backdoor](https://www.theregister.co.uk/2018/08/10/via_c3_x86_processor_backdoor/) through which regular applications can gain privileged execution.
**USB-based** (Type I): USB devices of all kinds can be reprogrammed with a malicious firmware capable of interacting with the operating system in nefarious ways. This is the case of the [BadUSB technique](https://arstechnica.com/information-technology/2014/07/this-thumbdrive-hacks-computers-badusb-exploit-makes-devices-turn-evil/), demonstrated few years ago, which allows a reprogrammed USB stick to act as a keyboard that sends commands to machines via keystrokes, or as a network card that can redirect traffic at will.
**USB-based** (Type I): USB devices of all kinds can be reprogrammed with a malicious firmware capable of interacting with the operating system in nefarious ways. This is the case of the [BadUSB technique](https://arstechnica.com/information-technology/2014/07/this-thumbdrive-hacks-computers-badusb-exploit-makes-devices-turn-evil/), demonstrated few years ago, which allows a reprogrammed USB stick to act as a keyboard that sends commands to machines via keystrokes, or as a network card that can redirect traffic at will.
**BIOS-based** (Type I): A BIOS is a firmware running inside a chipset. It executes when a machine is powered on, initializes the hardware, and then transfers control to the boot sector. Its a very important component that operates at a very low level and executes before the boot sector. Its possible to reprogram the BIOS firmware with malicious code, as has happened in the past with the [Mebromi rootkit](https://www.webroot.com/blog/2011/09/13/mebromi-the-first-bios-rootkit-in-the-wild/).
**BIOS-based** (Type I): A BIOS is a firmware running inside a chipset. It executes when a machine is powered on, initializes the hardware, and then transfers control to the boot sector. Its a very important component that operates at a very low level and executes before the boot sector. Its possible to reprogram the BIOS firmware with malicious code, as has happened in the past with the [Mebromi rootkit](https://www.webroot.com/blog/2011/09/13/mebromi-the-first-bios-rootkit-in-the-wild/).
**Hypervisor-based** (Type I): Modern CPUs provide hardware hypervisor support, allowing the operating system to create robust virtual machines. A virtual machine runs in a confined, simulated environment, and is in theory unaware of the emulation. A malware taking over a machine may implement a small hypervisor in order to hide itself outside of the realm of the running operating system. Malware of this kind has been theorized in the past, and eventually real hypervisor rootkits [have been observed](http://seclists.org/fulldisclosure/2017/Jun/29), although very few are known to date.