Third-party tooling or native logging features that offer access to process metadata (e.g., process names, internal names, known paths, etc.) are among the most effective data sources for observing or identifying renamed system utilities.
Most of our confirmed threat detections relating to renamed system utilities involve adversaries renaming known system binaries. Perhaps the most effective method for finding renamed system utilities is to compare the name embedded directly into the binary file (i.e., its internal name) with its externally presented name and generate alerts whenever those two names are different or deviate from what is expected. You can also compare expected process paths to the actual process paths—basing expected paths on what is normal for the binary given its internal name—to detect relocated system binaries that have not been renamed.
Our detection guidance for finding renamed system utilities can be categorized into four basic control groups that reliably offer insight into the true identity of a binary: known process names, paths, hash values, and command-line parameters. To detect deviations from what is known or expected, consider the following.
For known process names: Consider alerting on any activity where the process name does not match a list of known process names given an internal name. As an example, the internal name for
powershell.exe is PowerShell, and its known process names include
For known process paths: Consider alerting on any activity where a process path does not match a list of known process paths given an internal name. As an example: the known expected process path associated with
cscript.exe (based on its internal name) should be
For known hash values: While process names may change, the hash value associated with them should not. Therefore, if you have a list of matching hash values in an environment, consider alerting on or examining any that have a different process name. Since adversaries typically copy binaries that are already on disk, a renamed system utility should have the same hash as the original. You can find these deviations by investigating the suspect hash and reviewing observed paths.
For known command-line parameters for system processes: Considering detecting any apparent processes executing in conjunction with command-line parameters that are generally associated with a different process. As an example, Invoke-Expressions (
iex) are associated with PowerShell, so it would be highly suspicious to see an invoke expression in a command line associated with a process that appears to be something other than PowerShell.
Weeding out false positives
Looking for process names (e.g.,
regsvr32.exe) outside of expected paths will generate false positives because many software developers bundle specific versions of a system process. For example, we often run into false positives on
rundll32’s unexpected paths for certain antivirus software. Identify any tools that exhibit this behavior and add them as exclusions to your toolset.