Aristotle once famously said, "Knowing yourself is the beginning of all wisdom." That adage holds as true today for the modern healthcare organization as it did for the people of ancient Greece.

Healthcare organizations falling victim to ransomware and other cyberattacks still happens at an alarming rate. While dwell times are decreasing, it is still not uncommon for attackers to dwell on a network for weeks to explore an organization’s internal infrastructure, exfiltrate data and ensure widespread compromise of devices, before they launch any malicious payloads.

If one considers how this behavior so often goes undetected, it makes one consider that perhaps we don’t know and understand the behaviors of our own IT infrastructure well enough. After all, if we can’t say with confidence what is normal behavior on our network, how are we ever supposed to identify, in a timely manner, something that is not normal?

We too often limit ourselves by solely focusing on tools that try to detect known bad, but often forget that clearly understanding known good can be just as, if not more, important.

In recent years, this understanding of what, as well as where, behaviors are supposed to be occurring on a given network has become increasingly critical as attackers have been shifting more and more to living-off-the-land strategies, where legitimate tools that are native to an operating system, or commonly installed on desktops and servers, are abused for malicious purposes.

LOL often provides an effective way to bypass security tooling, as many LOL techniques are difficult for security vendors to outright block without negatively impacting a portion of their customer base.

For example, endpoint security is sometimes bypassed by an attacker invoking the bcdedit command, built into Windows, that allows for computers to be booted into safe mode for troubleshooting and repair.

Powershell, cscript, wscript, certutil and numerous other commands and applications are routinely abused similarly. The LOLBAS project provides great insights into a plethora of ways these abuses can occur.

While the number of LOL techniques may seem overwhelming, it is possible to begin to take actions to curb the efficacy of various LOL techniques, if we consider the application of some basic data analytics.

We can start by using EDR or another endpoint security tool to begin detecting and logging the execution of LOL binaries that interest us, and then, over a period of time, collect a data set of executions that can help us establish a picture of how often a particular binary in executed, who executes it, where it executes from, etc.

Once we have this data, we can see that LOL techniques can typically be classified into one or more of several categories:

1. Binary is widely used. For example, PowerPoint.exe or another MS Office application is going to be widely used, and probably cannot be blocked without causing major issues. It will also likely make for a very noisy, and hence useless, alert, unless something can be done to refine it further. Binaries in the category should either be considered normal behavior for the environment, or, if they need to be locked down, need to be combined with other elements of an execution path or specific command line arguments used to invoke the binary. For example, blocking PowerPoint would be disastrous, but blocking PowerPoint from being used to launch Powershell, a common malware technique, may be entirely possible. The addition of an execution path or command line arguments into the detection may shift your detection into one of the other categories.

2. Binary is not used at all. It is not uncommon to find that not all of the binaries used in LOL attacks have any legitimate use in a given organization. You may find that even after months of data collection, there are no executions for certain LOL binaries. For example, the AT command, is a deprecated Windows command that due to its deprecated nature may no longer be used in an organization. Binaries that fall into this category are good candidates for a block and/or an alert trigger as the behavior is not normal for your network.

3. Binary is used by a specific subset of users and or machines. Binaries in this category provide an opportunity to limit behaviors to just portions of the network and opportunities to create alerts for any unsanctioned use. For example, it may be perfectly reasonable for someone in the finance department to have access to an FTP client for exchanging billing data or someone in IT to use an SSH client to connect to servers and network infrastructure. Launching of these executables may be normal activities for these users/machines, but FTP or SSH being launched from a nursing workstation is probably a good indicator of data exfiltration or lateral movement. We have an opportunity here to create rules which allow the behavior for some users/machines and block and alert to the behavior on others, so we can allow normal operations to continue unhindered while building our resiliency against attack. Remember the concept of herd immunity applies to cybersecurity as well, and making a large portion of our network resistant to a certain attack technique can help to protect the whole organization. Blocks don’t always need to be universal.

4. Binary is used in conjunction with specific locations. Some level of automation is not uncommon in many organizations, particularly as they grow larger and logon scripts (or other scripts) to map printers and carry out other routine IT tasks are not unusual. With some basic organization put into place, such as storing all of these scripts in a defined location (should be somewhat unique to your organization and not a generic OS path like C:\Program Files\), a bit of organizational knowledge can be leveraged to harden your environment. For example, if all the login scripts are stored in a secured network share called “LoginScripts” and these scripts are the only scripts needed to manage user endpoints, it becomes entirely possible to limit the use of the wscript interpreter (or whatever interpreter binary is leveraged) to just script executions that originate from that particular “LoginScripts” share. This way, the organization can leverage tools like wscript and Powershell, but also enhance their protections against malware that seeks to leverage the same tools, as the malware samples will be attempting to launch the execution from a different and unapproved location, which creates an ideal scenario for building a detection or blocking policy. As with the above category, there may be some researchers, data analytics staff, etc. who need to run scripts stored in other locations. But once again, blocks don’t always need to be universal to be effective, and restricting the use across the majority of endpoints can have a large positive impact on security. 

A thorough analysis of your environment may reveal some additional category options as well that can provide a basis for further baselining efforts. The key is to begin to use such analytics to begin to map out what behavior is normal for your particular environment and use the definition of normal to enhance the blocking of and/or alerting to any behaviors that deviate from this definition of normal.

By knowing ourselves we gain the necessary wisdom to more effectively identify and proactively stop threats to our organizations.

Christopher Frenz is information security officer and AVP of IT security at Mount Sinai South Nassau.