Living-off-the-Land blog series – part 1
17 January 2019
What is Living-off-the-Land (LotL)?
LotL can be defined as the practice of using native tools and resources on the victim network or hosts to carry out a cyberattack, rather than use custom tools and resources. LotL practice is not new, but the use of it becomes ever increasingly popular and has evolved from only being found in targeted attacks to more common attacks. Since LotL involves tools and resources native to the target, traditional detection and defensive measures are less affective at mitigating the threat.
In this blog series, we will discuss the following common practices for LotL, go in-depth about technical use-cases, and how to combat LotL. By the end you should have not only a better understanding of cyberattacks involving LotL, but also what defensive measures should be taken for mitigation. Additionally, manual identification of host or network anomalies which may indicate an intrusion attempt leveraging LotL tactics and techniques will be learned as well.
Breaking down LotL practice into categories
is not a specific cyberattack category, exploit, or campaign; rather it is the practice of using native tools and resources during an intrusion process. Therefore, several tactics, techniques and procedures (TTPs) during a cyber intrusion could be considered LotL. These TTPs can fall under one of the two categories below.
Double-edged tools, taken from the popular phrase “double-edged sword”, are tools native to the host and in most cases installed by default with the operating system. These tools, such as PsExec, Windows Management Instrument (WMI), and BITSAdmin, are commonly used by network or system administrators. Therefore, when an attacker leverages them as well, traditional security such as IDS/IPS do not alert because the activity is considered normal in that environment. Below we have listed a few of the more popular double-edged tools used by attackers, as well as examples of what could be done with them.
|Double-edged||Use-case during intrusion|
|PsExec||Use-case during intrusion|
|WMI||Lateral movement or installation of backdoors locally and remote.|
|Sc.exe||Interacts with Windows service controller to create services from Non-PE scripts and/or shellcode. This can also be used for privilege escalations where a writable executable is replaced with a meterpreter shell and the service is restarted.|
|Powershell||Administrative tool mainly used to load malware directly into memory without the need to write to disk.|
|Schtasks||Used to bypass User Access Control (UAC), escalate privileges, and setup malware persistence.|
In short, there are many cyberattack techniques that would fall under the fileless category. Fileless can be considered successful if the attackers do not write-to-disk the final payload or malware. Therefore, even the use of VBA scripts and Jscript load points in the registry can be considered fileless techniques. In these cases, the VBA scripts or Jscript load points in the registry are used as downloaders for malware, which are then loaded directly into memory rather than written to disk.
As popular as it was, the Code Red worm of 2001, was the first widespread case of a memory only malware, followed by SQL Slammer in 2003. Both malware families leveraged Windows services to execute their payload directly into memory without the need to write to disk. Memory only procedures mainly involve the effort to load a malicious payload of choice directly into memory, rather than write to disk. This reduces the artifacts and footprint of the attack significantly, making forensics harder and more reliant on the analysis of memory from a machine image which was not wiped following the actions-on-objective. This can typically be accomplished via one of the many remote code execution vulnerabilities in existence today, where successful exploitation will likely allow the shellcode to load a payload directly into memory. Dynamic payloads such as Meterpreter, make injecting a malicious Windows payload, either DLL or process injection, straight-forward, even ensuring the process and payload have the same architecture.
There are instances where double-edged tools are used with memory-only techniques for downloading and loading a malware payload directly in memory. For instance, ‘regsvr32.exe’ is a legitimate Windows process used to register and unregister OLE controls for DLL modules and ActiveX. Done correctly, the process can be used to download SCT files which then use WMI and PowerShell to download encrypted DLL into memory, otherwise known as reflective DLL loading. A prime example of this would be the Dromedan downloader.
Besides just relying on memory-only techniques, the Windows registry is a popular fileless load point for storing malware and malicious scripts. The Windows registry can be used to establish persistence by creating registry run keys and load points. Those keys and load points then reference malware or a script contained in the registry that are extracted and run on the fly. A popular example of registry resident malware is Poweliks from 2014. It utilized registry key obfuscation and modification of registry access rights to make identification and removal difficult. This type of malware would be considered, registry resident.
Why popularity is continuing and will continue to increase
Researchers from the Global Threat Intelligence Center (GTIC) believe LotL TTPs will only become more popular in time. With the continued adoption of data execution prevention (DEP), address space layout randomization (ASLR) and control-flow integrity (CFI), the discovery of 0-day vulnerabilities to be used in campaigns can be extremely difficult and exhaust resources. Therefore, focusing TTPs on native tools and resources not only saves resources, but reduced footprints and artifacts at the same time. In addition, LotL TTPs are becoming more than ever increasingly accessible within open-source and popular hacking frameworks and tools such as MetaSploit, PowerSploit, Exploit Pack and more. Not to mention commodity malware which can be rented or purchased for cheap already includes LotL functionality when sold. The detection and analysis of LotL being used in cyber-attacks is no longer indication of an advanced threat actor group or robust malware, but nevertheless, detection and mitigation still proves to be difficult for most organizations and even security teams.
What can you do?
For now I recommend hiding under your desk and unplugging everything and, if already compromised, burying your head in the sand like an ostrich. Of course, these are not the defensive measures and tactics for combatting LotL-based cyberattacks, but this blog series will go into depth them. So stay tuned and be sure to follow this blog series if you are serious about reducing the risk of being a victim to LotL. In part 2, we will cover in-depth the TTPs more in-depth from a technical perspective in this blog series.