Aristotle once said, “Knowing oneself is the beginning of all wisdom.” That saying is as valid today for the modern healthcare organization as it was for the people of ancient Greece.
Healthcare organizations falling victim to ransomware and other cyberattacks continue to occur at an alarming rate. While dwell times are decreasing, it is still not uncommon for attackers to remain on a network for weeks to explore an organization’s internal infrastructure, exfiltrate data, and ensure widespread compromise of devices, before launching any malicious payloads.
If one considers how this behavior often goes unnoticed, it leads us to consider that perhaps we do not know or understand the behaviors of our own IT infrastructure well enough. After all, if we can’t say with confidence what normal behavior is on our network, how are we supposed to be able to identify, in a timely manner, something that isn’t normal?
Too often we limit ourselves to focusing solely on tools that attempt to detect known bad, but we often forget that clearly understanding known good can be just as important, if not more so.
In recent years, this understanding of what behaviors are supposed to occur, as well as where, on a given network has become increasingly critical as attackers have increasingly shifted toward subsistence strategies, where legitimate tools that are either native to an operating system, or commonly installed on desktop computers and servers, and abused for malicious purposes.
LOL often provides an effective way to bypass security tools, as many LOL techniques are difficult for security vendors to block without negatively impacting a portion of their customer base.
For example, an attacker sometimes bypasses endpoint security by invoking the bcdedit command, built into Windows, which allows computers to start in safe mode for troubleshooting and repair purposes.
Similarly, Powershell, cscript, wscript, certutil, and many other commands and applications are routinely abused. He LOLBÁS Project provides great insights into a host of ways these abuses can occur.
While the number of LOL techniques may seem overwhelming, it is possible to begin taking steps to curb the effectiveness of various LOL techniques by considering the application of some basic data analysis.
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 is run, who runs it, where it is run from, etc.
Once we have this data, we can see that LOL techniques can typically be classified into one or more of several categories:
-
Binary is widely used. For example, PowerPoint.exe or another MS Office application will be used extensively and probably cannot be blocked without causing major problems. It is also likely to generate a very noisy and therefore useless alert unless something can be done to refine it further. Binaries in the category should be considered normal behavior for the environment or, if blocking is required, should 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 the use of PowerPoint to launch Powershell, a common malware technique, may be entirely possible. Adding an execution path or command line arguments to the detection can change your detection to one of the other categories.
-
The binary is not used at all. It is not uncommon to find that not all binaries used in LOL attacks have any legitimate use in a given organization. It is possible that even after months of data collection, there may be no runs for certain LOL binaries. For example, the AT command is a deprecated Windows command that, due to its deprecated nature, can no longer be used in an organization. Binaries that fall into this category are good candidates for a block and/or alert trigger since the behavior is not normal for your network.
-
The binary is used by a specific subset of users or machines. Binaries in this category provide the opportunity to limit behaviors to only parts of the network and opportunities to create alerts for any unauthorized use. For example, it may be perfectly reasonable for someone in finance to have access to an FTP client to exchange billing data or for someone in IT to use an SSH client to connect to servers and network infrastructure. Launching these executables may be a normal activity for these users/machines, but launching FTP or SSH from a nursing workstation is probably a good indicator of a data breach or lateral movement. Here we have the opportunity to create rules that allow the behavior of some users/machines and block and alert on the behavior of others, so that we can allow normal operations to continue unimpeded while building our resilience against attacks. Remember that the concept of herd immunity also applies to cybersecurity, and making a large portion of our network resistant to a particular attack technique can help protect the entire organization. It is not always necessary for blocks to be universal.
-
The binary is used in conjunction with specific locations. Some level of automation is not uncommon in many organizations, particularly as they grow, and login scripts (or other scripts) to map printers and perform other routine IT tasks are not unusual. With some basic organization in place, such as storing all of these scripts in a defined location (this should be something unique to your organization and not a generic OS path like C:\Program Files\), a little organizational knowledge can be leveraged. to harden your environment. For example, if all login scripts are stored on a secure network share called “LoginScripts” and these scripts are the only ones needed to manage user endpoints, it is entirely possible to limit the use of the wscript interpreter ( or any binary interpreter). leveraged) to only script executions originating from that particular “LoginScripts” share. This way, the organization can take advantage of tools like wscript and Powershell, but also improve its protection against malware that seeks to take advantage of the same tools, as malware samples will attempt to initiate execution from a different, unapproved location, creating an ideal situation. scenario to build a detection or blocking policy. As with the previous category, it is possible that some researchers, data analysis personnel, etc. need to run scripts stored in other locations. But again, locks don’t always have to be universal to be effective, and restricting their use on most endpoints can have a big positive impact on security.
A thorough analysis of your environment may also reveal some additional category options that may provide a basis for additional benchmarking efforts. The key is to start using such analytics to begin mapping out what behavior is normal for your particular environment and use the definition of normal to improve blocking and/or alerting on any behavior that deviates from this definition of normal.
By knowing ourselves we gain the wisdom necessary to more effectively identify and proactively stop threats to our organizations.
at Mount Sinai South Nassau.
