{"id":22522,"date":"2024-03-22T12:39:46","date_gmt":"2024-03-22T16:39:46","guid":{"rendered":"https:\/\/me-en.kaspersky.com\/blog\/lotl-attacks-detection-hardening-guidance\/22522\/"},"modified":"2024-03-25T20:25:16","modified_gmt":"2024-03-25T16:25:16","slug":"lotl-attacks-detection-hardening-guidance","status":"publish","type":"post","link":"https:\/\/me-en.kaspersky.com\/blog\/lotl-attacks-detection-hardening-guidance\/22522\/","title":{"rendered":"How to prepare for Living Off the Land (LotL) attacks"},"content":{"rendered":"<p>Should serious-minded attackers choose namely your company to target, they\u2019d certainly be looking to gain a long-term, persistent presence in your infrastructure. Some would deploy high-end malware to achieve this \u2013 but others prefer not to. Many, in fact, prefer to attack companies by exploiting <a href=\"https:\/\/www.kaspersky.com\/blog\/log4shell-still-active-2022\/46545\/\" target=\"_blank\" rel=\"noopener nofollow\">vulnerabilities<\/a>, <a href=\"https:\/\/www.kaspersky.com\/blog\/password-leaks\/45296\/\" target=\"_blank\" rel=\"noopener nofollow\">stolen credential<\/a>, and <em>legitimate<\/em> programs that are <strong>already<\/strong> in the system. This technique \u2013 known as <a href=\"https:\/\/encyclopedia.kaspersky.com\/glossary\/lotl-living-off-the-land\/\" target=\"_blank\" rel=\"noopener\">Living off the Land (LotL)<\/a> \u2013 has many advantages from an attacker\u2019s point of view:<\/p>\n<ul>\n<li>Malicious activity blends in with everyday network and administrative activities.<\/li>\n<li>Tools already installed on computers are less likely to trigger endpoint protection (EPP).<\/li>\n<li>There\u2019s no need to spend time <em>and<\/em> resources on developing one\u2019s own malicious tools.<\/li>\n<li>Such activity doesn\u2019t produce obvious indicators of compromise (IoC), making it hard to trace malicious activity and compare attacks across organizations.<\/li>\n<li>Many companies fail to collect and store information about network monitoring and day-to-day network activity in sufficient detail, so it\u2019s impossible to track the evolution of an attack in real time \u2013 much less historically. This makes preventing attacks and mitigating their consequences extremely tricky.<\/li>\n<\/ul>\n<p>LotL tactics are used by various groups: spy groups (see <a href=\"https:\/\/securelist.com\/cycldek-bridging-the-air-gap\/97157\/\" target=\"_blank\" rel=\"noopener\">here<\/a> and <a href=\"https:\/\/securelist.com\/modern-asia-apt-groups-ttp\/111009\/\" target=\"_blank\" rel=\"noopener\">here<\/a>), <a href=\"https:\/\/securelist.com\/bluenoroff-methods-bypass-motw\/108383\/\" target=\"_blank\" rel=\"noopener\">money-minded cybercriminals<\/a>, and <a href=\"https:\/\/securelist.com\/modern-ransomware-groups-ttps\/106824\/\" target=\"_blank\" rel=\"noopener\">ransomware gangs<\/a>.<\/p>\n<h2>Environments prone to LotL attacks<\/h2>\n<p>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 \u2013 a reference to, yes, apples. In each of these environments, attackers have a variety of tools and techniques at their disposal:<\/p>\n<ul>\n<li><strong>Windows<\/strong>Tools useful to attackers are usually called LOLBins (LOL binaries) or LOLBAS (LOL binaries and scripts). We <a href=\"https:\/\/www.kaspersky.com\/blog\/most-used-lolbins\/42180\/\" target=\"_blank\" rel=\"noopener nofollow\">analyzed the most popular LOLBins<\/a>; a more complete list of all Windows tools seen in attacks can be found in <a href=\"https:\/\/lolbas-project.github.io\/\" target=\"_blank\" rel=\"nofollow noopener\">this GitHub repository<\/a>. To escalate privileges and disable defenses, threat actors can exploit legitimate software drivers, a list of which is available at <a href=\"https:\/\/www.loldrivers.io\/\" target=\"_blank\" rel=\"nofollow noopener\">loldrivers.io<\/a>.<\/li>\n<li><strong>Unix\/Linux.<\/strong> An extensive list of tools exploited by attackers can be found in the <a href=\"https:\/\/gtfobins.github.io\/\" target=\"_blank\" rel=\"nofollow noopener\">gtfobins repository on GitHub<\/a>.<\/li>\n<li><strong>macOS<\/strong>. \u201cOrchard\u201d tools used in attacks are available at <a href=\"https:\/\/www.loobins.io\/\" target=\"_blank\" rel=\"nofollow noopener\">loobins.io<\/a>.<\/li>\n<\/ul>\n<p>It should be reiterated here that all the files listed in the links above are legitimate tools. They aren\u2019t vulnerable per se, but can be used by an attacker who\u2019s penetrated a system and gained sufficient privileges.<\/p>\n<h2>What\u2019s stopping you from detecting LotL?<\/h2>\n<p>Even if an organization has a high level of information security maturity \u2013 with an expert team and advanced protective tools \u2013 in practice, defenders may be hampered in detecting LotL attacks due to the following reasons:<\/p>\n<ul>\n<li><strong>Non-adapted settings.<\/strong> 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 <a href=\"https:\/\/me-en.kaspersky.com\/enterprise-security\/threat-intelligence?icid=me-en_kdailyplacehold_acq_ona_smm__onl_b2b_kasperskydaily_wpplaceholder_______\" target=\"_blank\" rel=\"noopener\">threat intelligence<\/a> and known characteristics of the company. Sometimes defenders rely too heavily on IoC detection, and don\u2019t 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\u2019re legitimate applications. All of the above significantly lowers the effectiveness of protection.<\/li>\n<li><strong>Inadequate logging.<\/strong> The standard level of logging in many systems doesn\u2019t 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.<\/li>\n<li><strong>Insufficient automation.<\/strong> 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 obtained with the he help of an <a href=\"https:\/\/me-en.kaspersky.com\/enterprise-security\/endpoint-detection-response-edr?icid=me-en_kdailyplacehold_acq_ona_smm__onl_b2b_kasperskydaily_wpplaceholder_______\" target=\"_blank\" rel=\"noopener\">EDR<\/a> solution, 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.<\/li>\n<li><strong>Isolation from IT.<\/strong> 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\u2019t talk to each other, an investigation into suspicious activity can drag on for weeks or even months \u2013 during all of which time the threat actors would be further developing their attacks.<\/li>\n<\/ul>\n<h2>How to detect LotL attacks<\/h2>\n<p>There are many practical cybersecurity recommendations for detecting LotL attacks \u2013 none of them exhaustive. The most recent and detailed public <a href=\"https:\/\/www.cyber.gov.au\/about-us\/view-all-content\/alerts-and-advisories\/identifying-and-mitigating-living-off-the-land-techniques\" target=\"_blank\" rel=\"nofollow noopener\">guidance<\/a> comes from cyber agencies in the US, UK, and Australia. But even there, the authors emphasize that they\u2019re only providing best practice benchmarks.<\/p>\n<p>The most practical, effective, and implementable detection tips are as follows:<\/p>\n<ol>\n<li><strong>Implement detailed event logging.<\/strong> Collect logs in a centralized repository that\u2019s 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.<br>\n\u00a0<br>\nTo be useful, logs must be comprehensive and verbose. They must log security events \u2013 including all commands in management consoles (shells), as well as system calls, PowerShell activity, WMI event traces, and so on. It\u2019s worth reiterating that standard logging configurations rarely cover all necessary events. What\u2019s 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 <a href=\"https:\/\/arstechnica.com\/tech-policy\/2023\/07\/microsoft-to-stop-locking-vital-security-logs-behind-57-per-user-monthly-plan\/\" target=\"_blank\" rel=\"nofollow noopener\">revised its policy<\/a>.<br>\n\u00a0<br>\nFor proper implementation of logging, SIEM (centralization, aggregation, and event analysis) and <a href=\"https:\/\/me-en.kaspersky.com\/enterprise-security\/endpoint-detection-response-edr?icid=me-en_kdailyplacehold_acq_ona_smm__onl_b2b_kasperskydaily_wpplaceholder_______\" target=\"_blank\" rel=\"noopener\">EDR<\/a> (collection of necessary telemetry from hosts) are indispensable tools.<\/li>\n<li><strong>Identify and record typical, day-to-day activity<\/strong> 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 \u201cadministrative\u201d behavior, and the use of specific tools by privileged accounts \u2013 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\u2019s 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.<\/li>\n<li><strong>Use automated systems<\/strong> (such as machine learning models) to continuously analyze logs, match them against typical activity, and <strong>report anomalies to InfoSec<\/strong>. Ideally, implement <a href=\"https:\/\/encyclopedia.kaspersky.com\/glossary\/ueba\/\" target=\"_blank\" rel=\"noopener\">user and entity behavior analytics (UEBA)<\/a>.<\/li>\n<li>Continuously update settings to <strong>reduce background noise<\/strong> and adjust low-impact alerts or downgrade their priority.<br>\n\u00a0<br>\nYou 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 \u201cCommandLine=*\u201d. 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.<\/li>\n<\/ol>\n<h2><strong>How to defend against LotL<\/strong><\/h2>\n<p>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.<\/p>\n<ol>\n<li>Review and implement \u201chardening\u201d recommendations from vendors of the hardware and applications you use. The following should be considered as the minimum:<\/li>\n<\/ol><ul>\n<li>For Windows systems, apply Microsoft updates promptly.<\/li>\n<li>For Linux systems, review permissions for key applications and daemons by following an industry guide \u2013 such as <a href=\"https:\/\/www.cisecurity.org\/benchmark\/red_hat_linux\" target=\"_blank\" rel=\"nofollow noopener\">Red Hat Enterprise Linux Benchmarks<\/a>.<\/li>\n<li>For macOS devices, be aware that there are no generally accepted hardening recommendations, but there is a misconception that they\u2019re 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 <a href=\"https:\/\/github.com\/usnistgov\/macos_security\" target=\"_blank\" rel=\"nofollow noopener\">macOS Security Compliance Project<\/a>, which lets you generate InfoSec recommendations for specific macOS devices.<\/li>\n<li>For organizations that actively use Microsoft 365 and Google Workspace cloud services, it\u2019s vital to implement the minimum InfoSec recommendations from <a href=\"https:\/\/www.cisa.gov\/resources-tools\/services\/secure-cloud-business-applications-scuba-project#:%7E:text=Microsoft%20365%20%26%20Google%20Workspace%20Baselines\" target=\"_blank\" rel=\"nofollow noopener\">Microsoft<\/a> and <a href=\"https:\/\/www.cisa.gov\/resources-tools\/services\/secure-cloud-business-applications-scuba-project\" target=\"_blank\" rel=\"nofollow noopener\">Google<\/a>.<\/li>\n<li>Critical IT assets, such as <a href=\"https:\/\/learn.microsoft.com\/en-us\/security\/privileged-access-workstations\/privileged-access-access-model#evolution-from-the-legacy-ad-tier-model\" target=\"_blank\" rel=\"nofollow noopener\">ADFS and ADCS for Microsoft-based IT systems<\/a>, warrant special attention and in-depth analysis of possible hardening measures.<\/li>\n<li>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.<\/li>\n<\/ul>\n<li>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\u2019t use for work and your system processes don\u2019t 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.<br>\n\u00a0<br>\nConduct an in-depth inventory of configurations, policies, and software installed on each host. If an application isn\u2019t 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.<\/li>\n<li>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.\n<p>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\u2019s imperative to specify precise IP ranges and keep the allowlist as short as possible.<\/p>\n<p>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).<\/p>\n<p>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.<\/p><\/li>\n<li>Implement authentication and authorization for all human-machine and machine-machine interactions regardless of their network location.<\/li>\n<li>Implement a comprehensive approach to infrastructure protection based on detection and response tools (SIEM + <a href=\"https:\/\/me-en.kaspersky.com\/enterprise-security\/endpoint-detection-response-edr?icid=me-en_kdailyplacehold_acq_ona_smm__onl_b2b_kasperskydaily_wpplaceholder_______\" target=\"_blank\" rel=\"noopener\">EDR<\/a>), building both awareness and team expertise (<a href=\"https:\/\/me-en.kaspersky.com\/enterprise-security\/threat-intelligence?icid=me-en_kdailyplacehold_acq_ona_smm__onl_b2b_kasperskydaily_wpplaceholder_______\" target=\"_blank\" rel=\"noopener\">threat intelligence<\/a> + cybersecurity training), and continuous hardening of the company\u2019s overall InfoSec posture.<\/li>\n\n<input type=\"hidden\" class=\"category_for_banner\" value=\"mdr\"><input type=\"hidden\" class=\"placeholder_for_banner\" data-cat_id=\"mdr\" value=\"18953\">\n","protected":false},"excerpt":{"rendered":"<p>To go undetected, attackers can operate in your network without any malware at all. How to detect them and prevent damage? <\/p>\n","protected":false},"author":2722,"featured_media":22523,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1318,1916,1917],"tags":[2294,2746,2747,2748,2749,192,2097,2494,521,131,2297],"class_list":{"0":"post-22522","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-enterprise","9":"category-smb","10":"tag-edr","11":"tag-lolbas","12":"tag-lolbin","13":"tag-lotl","14":"tag-monitoring","15":"tag-protection","16":"tag-siem","17":"tag-strategy","18":"tag-threats","19":"tag-tips","20":"tag-xdr"},"hreflang":[{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/lotl-attacks-detection-hardening-guidance\/22522\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/lotl-attacks-detection-hardening-guidance\/27214\/"},{"hreflang":"en-us","url":"https:\/\/usa.kaspersky.com\/blog\/lotl-attacks-detection-hardening-guidance\/29890\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/lotl-attacks-detection-hardening-guidance\/27389\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/lotl-attacks-detection-hardening-guidance\/37163\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/lotl-attacks-detection-hardening-guidance\/50826\/"},{"hreflang":"ja","url":"https:\/\/blog.kaspersky.co.jp\/lotl-attacks-detection-hardening-guidance\/36327\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/lotl-attacks-detection-hardening-guidance\/27573\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/lotl-attacks-detection-hardening-guidance\/33396\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/lotl-attacks-detection-hardening-guidance\/33023\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/me-en.kaspersky.com\/blog\/tag\/siem\/","name":"SIEM"},"_links":{"self":[{"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/22522","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/users\/2722"}],"replies":[{"embeddable":true,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/comments?post=22522"}],"version-history":[{"count":3,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/22522\/revisions"}],"predecessor-version":[{"id":22526,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/22522\/revisions\/22526"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/media\/22523"}],"wp:attachment":[{"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/media?parent=22522"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/categories?post=22522"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/tags?post=22522"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}