Despite spending millions of dollars annually on information security, organizations invariably realize that their security tools and controls—no matter how costly or advanced—have limitations. Whether it’s endpoint detection and response (EDR) or a firewall, you’re going to find blind spots. The trick is to identify these limitations early and often, and to compensate with controls that reduce the impact of blind spots so your team can continue to reap whatever benefits their tooling offers.
Unfortunately, adversaries are also aware of these blind spots, and they’ll take any opportunity to use them against you. For example, adversaries often encrypt their network traffic to nullify proxy controls or full-packet capture. Or, to bypass antivirus and signature-based scanning, they pack and encrypt payloads.
Scripting Away Visibility
One of the simplest ways to hinder visibility with EDR is to simply place malicious commands within scripts instead of process command lines. This is due to the nature of command shells in all platforms, and its effectiveness depends on which commands you build into a script. With any command shells, certain commands are considered internal commands. This means that the shell will not call an external program to execute code, it all happens within the shell. When these internal commands are executed as command line arguments to a process, EDR products can see them easily. When they are contained within a script or interactive session, not all EDR products can show them. Consider the following command:
Cmd.exe /c copy file1.txt file2.txt
This creates a copy of file1.txt and displays the “copy” data in EDR data as expected. When the same copy is contained within a script, visibility changes. In this case:
Cmd.exe /c C:\copy_file.bat
Some EDR products will not be able to show the copy operation, they will only show the creation of file2.txt. If your EDR product does not display the contents of a script or interactive session, you’d have to rely on capturing the executed script or a memory dump for further analysis.
On the other end of the spectrum, commands external to a shell should be easily visible within EDR data. Imagine the use of xcopy.exe instead of the copy internal command. Xcopy should always be visible as a child process of whatever shell executes it, even in script form. By piecing together the functionality of external commands observed when a script executes, you can surmise the larger purpose of the script without full visibility into its contents. You may not have 100 percent accuracy in guessing the script’s contents, but you’ll be able to determine whether a host needs deeper analysis for an incident.
Even though I cited cmd.exe for this technique, it is not the only command shell capable of these shenanigans. You can do the same for PowerShell using cmdlets, and you can use Bash or other shells with their respective internal commands. In the example screenshot, EDR data could not tell us what was in the malicious script, we had to rely on artifacts created by the script’s execution. No matter which shell or script is used, the principle is the same: keeping an eye on external command usage through child processes will help you build an idea of script contents.
Windows Management Instrumentation and Stored Payloads
Windows Management Instrumentation (WMI) is an administrator’s paradise with its ability to enumerate data about Windows systems, store more data, and enable endpoint management using any tool that can interact with WMI. Even though this technology is used by nearly every Windows administrator on the planet, it remains somewhat opaque since many administrators can’t inspect it as easily as a simple file on the desktop. Adversaries have used this to their advantage by stashing script payloads (like PowerShell commands) into WMI event consumers. Manipulation of WMI to store payloads appears similar to this shot.