Should serious-minded attackers choose namely your company to target, they’d certainly be looking to gain a long-term, persistent presence in your infrastructure. Some would deploy high-end malware to achieve this – but others prefer not to. Many, in fact, prefer to attack companies by exploiting vulnerabilities, stolen credential, and legitimate programs that are already in the system. This technique – known as Living off the Land (LotL) – has many advantages from an attacker’s point of view:

Malicious activity blends in with everyday network and administrative activities.
Tools already installed on computers are less likely to trigger endpoint protection (EPP).
There’s no need to spend time and resources on developing one’s own malicious tools.
Such activity doesn’t produce obvious indicators of compromise (IoC), making it hard to trace malicious activity and compare attacks across organizations.
Many companies fail to collect and store information about network monitoring and day-to-day network activity in sufficient detail, so it’s impossible to track the evolution of an attack in real time – much less historically. This makes preventing attacks and mitigating their consequences extremely tricky.

LotL tactics are used by various groups: spy groups (see here and here), money-minded cybercriminals, and ransomware gangs.

Environments prone to LotL attacks

LotL attacks can be carried out in any environment: cloud, on-premises, hybrid; on Windows, Linux, and macOS platforms. Incidentally, attacks on macOS are sometimes known as Living off the Orchard – a reference to, yes, apples. In each of these environments, attackers have a variety of tools and techniques at their disposal:

Tools useful to attackers are usually called LOLBins (LOL binaries) or LOLBAS (LOL binaries and scripts). We analyzed the most popular LOLBins; a more complete list of all Windows tools seen in attacks can be found in this GitHub repository. To escalate privileges and disable defenses, threat actors can exploit legitimate software drivers, a list of which is available at loldrivers.io.
Unix/Linux. An extensive list of tools exploited by attackers can be found in the gtfobins repository on GitHub.
macOS. “Orchard” tools used in attacks are available at io.

It should be reiterated here that all the files listed in the links above are legitimate tools. They aren’t vulnerable per se, but can be used by an attacker who’s penetrated a system and gained sufficient privileges.

What’s stopping you from detecting LotL?

Even if an organization has a high level of information security maturity – with an expert team and advanced protective tools – in practice, defenders may be hampered in detecting LotL attacks due to the following reasons:

Non-adapted settings. Even advanced security tools need to be adapted to the specifics of the organization and the particularities of network segmentation, user-server interaction, and typical IT-system operating scenarios. Correlation rules need to be created and customized based on the available threat intelligence and known characteristics of the company. Sometimes defenders rely too heavily on IoC detection, and don’t pay enough attention to potentially dangerous behavioral signals. Sometimes InfoSec or IT services use broad exclusion rules and extensive allowlists that include many LOLBAS simply because they’re legitimate applications. All of the above significantly lowers the effectiveness of protection.
Inadequate logging. The standard level of logging in many systems doesn’t allow for the detection of malicious activity, storage of event parameters sufficient for incident analysis, or reliable differentiation between legitimate administrative actions and malicious ones.
Insufficient automation. Malicious actions in a heap of logs can only be detected after preliminary filtering and removal of background noise. The most effective filtering is telemetry from EDR, which collects relevant telemetry, increases flexibility in detecting attacker techniques, and reduces false positives. Without filtering and automated analysis, logs are useless. There are simply too many of them.
Isolation from IT. The above issues would be especially acute if IT and InfoSec services have little interaction: InfoSec is unfamiliar with IT work regulations, tool settings, and so on. In addition, if the teams don’t talk to each other, an investigation into suspicious activity can drag on for weeks or even months – during all of which time the threat actors would be further developing their attacks.

How to detect LotL attacks

There are many practical cybersecurity recommendations for detecting LotL attacks – none of them exhaustive. The most recent and detailed public guidance comes from cyber agencies in the US, UK, and Australia. But even there, the authors emphasize that they’re only providing best practice benchmarks.

The most practical, effective, and implementable detection tips are as follows:

Implement detailed event logging. Collect logs in a centralized repository that’s write-once and disallows modifications. This prevents attackers from deleting or changing logs. Centralization of logs is critical because it enables behavioral analysis, retrospective searches, and targeted threat hunting. It also often makes it possible to save logs for longer periods of time.
 
To be useful, logs must be comprehensive and verbose. They must log security events – including all commands in management consoles (shells), as well as system calls, PowerShell activity, WMI event traces, and so on. It’s worth reiterating that standard logging configurations rarely cover all necessary events. What’s more, in some cloud environments, the right level of logging is only available as part of costly service packages. When Microsoft 365 customers got burned this last year, Microsoft revised its policy.
 
For proper implementation of logging, SIEM (centralization, aggregation, and event analysis) and EDR (collection of necessary telemetry from hosts) are indispensable tools.
Identify and record typical, day-to-day activity of network devices, servers, applications, users, and administrators. To gather information about baseline behavior in a particular network, SIEM is recommended: all normal sequences of events, service relationships and the like are clear to see. Special attention should be paid to the analysis of “administrative” behavior, and the use of specific tools by privileged accounts – including system ones. Keep the number of administrative tools to a minimum, with detailed logging of their operation; use of other similar tools should be either blocked or set to trigger alerts. For administrator accounts, it’s important to analyze what time they are in use, what commands they run and in what sequence, what devices they interact with, and so on.
Use automated systems (such as machine learning models) to continuously analyze logs, match them against typical activity, and report anomalies to InfoSec. Ideally, implement user and entity behavior analytics (UEBA).
Continuously update settings to reduce background noise and adjust low-impact alerts or downgrade their priority.
 
You can fine-tune monitoring rules and alert triggers to better distinguish between routine administrative actions and potentially dangerous behavior. Avoid overly broad rules that will burden systems and analysts alike, such as “CommandLine=*”. Work with the IT team to reduce the variety of administration utilities used, their accessibility on unrelated systems, and the number of available protocols and types of accounts for logging in to corporate systems.

How to defend against LotL

The very nature of these attacks makes it almost impossible to prevent them completely. However, proper configuration of your network, endpoints, applications, and accounts can dramatically narrow the attack surface, speed up detection, and minimize the damage caused by intrusion attempts.

Review and implement “hardening” recommendations from vendors of the hardware and applications you use. The following should be considered as the minimum:

For Windows systems, apply Microsoft updates promptly.
For Linux systems, review permissions for key applications and daemons by following an industry guide – such as Red Hat Enterprise Linux Benchmarks.
For macOS devices, be aware that there are no generally accepted hardening recommendations, but there is a misconception that they’re secure out-of-the-box. In mixed networks, Windows devices are often more prevalent, such that IT and InfoSec tend to focus on Windows, overlooking threats and suspicious events on Apple devices. Besides the advice to regularly update macOS to the latest version and implement EDR/EPP, we recommend studying the macOS Security Compliance Project, which lets you generate InfoSec recommendations for specific macOS devices.
For organizations that actively use Microsoft 365 and Google Workspace cloud services, it’s vital to implement the minimum InfoSec recommendations from Microsoft and Google.
Critical IT assets, such as ADFS and ADCS for Microsoft-based IT systems, warrant special attention and in-depth analysis of possible hardening measures.
Widely apply universal hardening measures such as minimizing the number of running services, the principle of least privilege, and encryption and authentication of all network communications.

Make the allowlisting (aka default deny) approach standard. If implementing it across all applications and all computers is troublesome, try a phased approach. Popular LOLBAS that your team doesn’t use for work and your system processes don’t need can be blocked. The tools that actually are needed should only be available to administrators, only on relevant systems, and only for the duration of administrative tasks. All sessions that use such tools must be carefully logged and analyzed for anomalies.
 
Conduct an in-depth inventory of configurations, policies, and software installed on each host. If an application isn’t needed on a host, remove it: this will take it out of the toolkit of attackers and eliminate the headaches associated with updates and vulnerabilities. EDR solutions are ideal for this task.
Strengthen IT and OT network segmentation and monitoring at the internal network level. Besides isolating the OT network, you can move administrative machines with high privileges, important servers and the like to a separate subnet.

When implementing such restrictions, many organizations allowlist excessively broad IP ranges, for example, all addresses of a particular cloud provider. Even if this cloud hosts legitimate servers that the company server needs to communicate with, neighboring IPs could be leased by attackers. Therefore, it’s imperative to specify precise IP ranges and keep the allowlist as short as possible.

Network analysis tools should also be used to monitor traffic between segments, with a focus on unusual sessions and communications with more important network segments. Such analysis requires deep packet inspection (DPI).

To significantly simplify monitoring and to make attacks much harder, introduce privileged access workstations (PAWs) in your organization. High-risk administrative actions should be allowed on these and nowhere else. As part of the minimum program for Windows environments, operations with Active Directory servers should be allowed from PAWs only.

Implement authentication and authorization for all human-machine and machine-machine interactions regardless of their network location.
Implement a comprehensive approach to infrastructure protection based on detection and response tools (SIEM + EDR), building both awareness and team expertise (threat intelligence + cybersecurity training), and continuous hardening of the company’s overall InfoSec posture.

Kaspersky official blog – ​Read More