Living off the Land: Threats Looming From Within

Living off the Land (LOTL) involves taking advantage of functionality in binaries, scripts, and libraries native to the operating system OS. Living off the Land binaries and scripts (LOLBAS) as well as libraries exist in software or OS updates and can go undocumented. Common LOLBAS and libraries exploited by threat actors include:

• powershell.exe
• psexec.exe
• bitsadmin.exe 
• regsvr32.exe
• certutil.exe
• wmic.exe
• mshta.exe
• mofcomp.exe
• cmstp.exe
• windbg.exe
• cdb.exe
• msbuild.exe
• csc.exe

Attackers manipulate these executables to download, install, and execute malicious code on an infected host or within a victim’s environment. LOLBAS can also help threat actors bypass user account controls or application controls, such as Windows Defender Application Control. LOLBAS abuse gives threat actors increased freedom of movement on a victim network.

Common Tools for Living off the Land

The Cyber Threat Intelligence (CTI) team at the Multi-State Information Sharing and Analysis Center (MS-ISAC) sees lots of different instances of cyber threat actors (CTAs) engaging in LOLBAS abuse. But some techniques are more common than others. Provided below are just a few of them:

PowerShell

PowerShell is a command shell built on Windows management and .NET frameworks often used for legitimate IT administration. Security policies can prevent the execution of untrusted code. However, these restrictions can be bypassed and disabled depending on environment/configuration. 

Major ransomware and malware variants use PowerShell for a variety of tasks once in victim environments. For example, REvil uses PowerShell to delete volume shadow copies and download files. Pysa uses PowerShell scripts to deploy its ransomware, stop services such as Windows Defender, delete shadow copies, modify local accounts, broadcast MAC addresses, and modify README files to allow double-click opening. Hancitor, a common downloader, uses PowerShell to execute commands, download files, and execute payloads.  

PsExec

PsExec acts as a telnet-replacement that allows users to run Windows Server processes on remote systems via Server Message Block (SMB). This tool also offers interactivity for console applications without needing to manually install client software. PsExec behavior follows three primary steps:

1. Establish SMB network connection to a target system using admin credentials.
2. Push a copy of PSEXESVC.EXE to the target system's ADMIN$ share.
3. Launch PSEXESVC.ECE, which sends input and output to a named pipe.
1. Named pipes are interprocess communication methods. Pipes can be named for specific uses. Example pipe for PsExec communication: \\. \pipe\psexesvc.

For adversaries, PsExec can be abused for arbitrary command shell execution and lateral movement. Attackers also utilize it for propagation and remote execution of ransomware. Notable ransomware variants using PsExec include DoppelPaymer, Ryuk, Sodinokibi, and Nefilim.

BITSAdmin

Microsoft's Background Intelligent Transfer Service (BITS) is a service that coordinates downloading and uploading files, specifically large files. Attackers using BITS can evade firewalls blocking malicious or unknown processes by using malicious applications to create BITS jobs. Transferring files via BITS also allows attackers to maintain persistence in a target environment. Transfers are user-specified notification commands that are stored in a database instead of a registry, which means they can evade registry-based detection mechanisms.

Mandiant reporting identifies ransomware operators using BITSAdmin to activate KEGTAP. KEGTAP is a Bazarloader variant used to deploy follow-on tools such as Cobalt Strike, Brute Ratel, PowerShell Empire, Metasploit, or in some cases Ryuk ransomware. In the case of Ryuk, malicious BITS jobs attempt HTTP transfers of a nonexistent file from a local host. Given this file does not exist, BITS triggers the error state and launches the SetNotifyCommand line to execute KEGTAP. KEGTAP then fetches the desired malware to be deployed on the victim machine.   

Regsvr32.exe

Regsvr32 is used to register and unregister object linking and embedding controls, including dynamic link libraries (DLLs) on Windows systems. Regsvr32 allows attackers to execute code by staging resources locally or loading from a remote location without detection. Security tools may not monitor execution of and modules loaded by Regsvr32 because of allowlists or false positives from Windows using regsvr32.exe for legitimate operations.

IcedID campaigns are known to use Regsvr32 to run DLLs related to initial infection activity. Successful phishing campaigns lead to a victim opening a malicious Word document and enabling malicious macros embedded within the document. This generates an HTTP request to external resources that return a Windows DLL file. The DLL file is saved on the victim host in the same directory as the Word document and then accessed by the native regsvr32.exe process. 

wmic.exe

Windows Management Instrumentation (WMI) is a native Windows utility used to automate tasks and remotely manage systems. CTAs often use WMI in the same way administrators do: by executing processes on remote systems. Attackers can also leverage WMI to avoid detection based on process ancestry, such as by using a Microsoft Office macro to set a WMI event consumer to launch a malicious PowerShell command. This would circumvent tools set to monitor PowerShell activity originating from Office macros. Additionally, CTAs use WMI to enumerate user accounts or system information for reconnaissance purposes.

Preventing LOLBAS Abuse

Application allowlisting can be used to thwart the abuse of the tools discussed above so long as they are configured directly. Below is a list of specific recommendations for the programs listed above:

PowerShell 

Using command-line parameters can detect potentially malicious PowerShell behavior. Anti-Malware Scan Interface (AMSI), script-block, and System Monitor (Sysmon) are useful applications for this purpose. Security teams should configure systems for centralized logging that allows for analysis of threat hunting and incident response teams. PowerShell can be configured to log execution of all executed code blocks to Windows event log. By doing this, security teams can better understand code that needs to be deobfuscated before it can be run. Execution of deobfuscated code will be visible in Windows event logs.  

Watch for PowerShell execution that includes -encodedcommand arguments, as encoding and obfuscation are common bedfellows. Here are some example variations for shortened, encoded commands:

-e
-ec
-encodedcommand
-encoded
-enc
-en
-encod
-enco

Threat actors often obfuscate malicious code by including high counts of characters such as "^," "+," "$," and "%" or randomized case capitalization to evade detection mechanisms. By using regular expressions (regex), defenders can identify potentially anomalous activity by monitoring PowerShell execution with large amounts of special characters.

Flagging activity based solely on encoded commands will initially generate false positives. Begin by running queries offline to establish a baseline for volume, then identify patterns within decoded data. By creating a baseline of activity in an environment, defenders can understand what is considered normal for their environment.

PsExec 

Determine a baseline of named pipe use in your environment. This can generate noise in your detection with event logging, so be sure to exclude named pipes already known as benign. An example of common named pipes within Active Directory environments include:

\\.\pipe\netlogon
\\.\pipe\samr
\\.\pipe\lsarpc

Defenders should see an abundance of normal pipes, while abnormal ones will be uncommon. One way to limit noise is to reduce the use of specific processes so anomalous activity stands out. For example, switching to PowerShell Remoting, which has the same functionality as PsExec, can allow greater fidelity when detecting malicious PsExec activity. Lastly, defenders can detect lateral movement in their environment by investigating process names using binary metadata. Red Canary provides a few examples of what to look for:

• Binary internal name is psexec or Psexec Service Host, but the process name is not psexec.exe or psexesvc.exe.
• Binary internal name is remcom, but the process name is not remcom.exe or RemComSvc.exe.
• Binary internal name includes paexec, but the process name does not contain paexec.
• Binary internal name includes csexec, but the process name does not contain csexec.

BITSAdmin

Microsoft BITS runs as a service. To monitor BITS, check its status with the Sc query utility: sc query bits. Enumerate BITS tasks using the BITSAdmin tool: bitsadmin /list /allusers /verbose.

Recommended command options to monitor in BITSAdmin include:

‘Transfer,’ 'Create,' 'AddFile,' 'SetNotifyFlags,' 'SetNotifyCmdLine,' 'SetMinRetryDelay,' 'SetCustomHeaders,' and 'Resume.'

Additionally, monitor Admin log, PowerShell logs, and the Windows Even log for BITS activity. When monitoring BITS, keep in mind BITS jobs use HTTP(S) and SMB for remote connections and remain tied to the creating user. These jobs will only function when that user is logged on, even if the user attaches the job to a service account.

To mitigate malicious BITS activity, consider modifying network and host firewall rules and network controls to only allow legitimate BITS traffic. Reduce the default BITS job lifetime in Group Policy or edit the JobInactivityTimeout and MaxDownloadTime registry values in

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\BITS. Lastly, limit access to the BITS interface to specific users or groups.

Regsvr32.exe

Process monitoring represents one of the most effective ways to detect malicious use of regsvr32.exe, particularly with Sysmon or commercial EDR tools. Data sources associated with regsvr32 include loaded DLLs, process monitoring, process command-line parameters, and the Windows registry. When auditing logs, look for file modification either during staging of a local resource or as an artifact of remote resource load. Network connections initiated by regsvr32.exe processes should also be closely examined.

For mitigation, AppLocker can be used to designate PowerShell permissions and give access to certain users. This technique also works with other LOL-ware binaries, as well.

An additional mitigation technique for regsvr32 exploitation is to use Windows Firewall to turn off regsvr32's internet access. This will prevent threat actors from executing remote scriptlets.

wmic.exe

Detection of malicious WMI can be done by conducting thorough command line auditing. Sysmon is a great option for log auditing. It is a device driver created and maintained by Microsoft. The key to using Sysmon effectively is through filtering to ensure logs do not overwhelm your organization's collection capability. An example is listed below. WMI Events can be used to employ backdoors and maintain persistence. These events have corresponding consumers stored in the local WMI repository within the file system. In order to detect these kinds of attacks, PowerShell remoting is a recommended course of action. PowerShell commands to collect WMI event filters, consumers, and binding on a system include:

• Get-WMIObject -Namespace root\Subscription -Class __EventFilter
• Get-WMIObject -Namespace root\Subscription -Class __EventConsumer
• Get-WMIObject -Namespace root\Subscription -Class __FilterToConsumerBinding

PowerShell remoting allows collection of this data at scale. If possible, store results in something similar to Elasticsearch, or a database where anomalies can be more easily filtered and sorted across thousands of systems.

LOLBAS Abuse an Ongoing Trend

CTAs continually seek to conceal malicious activity in victim environments in order to evade IPS/IDS. In fact, the CTI team at MS-ISAC assesses with moderate confidence that threat actors will increasingly prefer Living off the Land techniques until security professionals are able to successfully catalog and monitor native operating system (OS) executables as well as trusted applications on their networks.

In addition to the recommendations discussed above, defenders should can set up alerts for when LOLBAS and libraries are used outside of planned maintenance windows, as this behavior should be investigated. Organizations can also use Windows Defender Application Control and reference Microsoft's policy block file to accomplish this. Finally, U.S. State, Local, Tribal, and Territorial (SLTT) organizations should consider becoming a part of the MS-ISAC for additional resources and tools that can help them defend against LOTL techniques.