OpenWith.exe Executes Specified Binary

This technique leverages OpenWith.exe as a proxy execution mechanism to run arbitrary code while blending in with legitimate system activity. It is a trusted Windows binary that is typically used when a user selects “Open with…” to choose an application for a file. Signed by Microsoft and commonly present on all systems, security controls often treat it as benign. An attacker abuses this trust by invoking OpenWith.exe and passing crafted command-line arguments (such as /c) that cause it to indirectly execute another program or command.

The attacker’s goal is not that OpenWith.exe itself is inherently powerful, but that it serves as a living-off-the-land binary (LOLBIN). By chaining execution through a trusted binary, the attacker can evade application allowlisting (e.g., AppLocker or WDAC), bypass simplistic detections that rely on known malicious executables, and reduce the likelihood of raising immediate suspicion. Security tools that focus on suspicious binaries may overlook activity if it originates from a signed system executable.

Another advantage is defense evasion through telemetry obfuscation. When an analyst reviews process trees, seeing OpenWith.exe may initially appear normal or user-driven. This forces defenders to dig deeper into command-line arguments and parent-child relationships, increasing the attacker’s chance of remaining undetected for longer.

Additionally, attackers may use this technique as part of a larger chain, where OpenWith.exe is launched by another script or LOLBin, further complicating attribution. This layering makes it harder to quickly distinguish malicious activity from legitimate user behavior.

In summary, an attacker uses this method because it provides stealth, trust exploitation, and execution flexibility, allowing malicious commands to run under the cover of a legitimate Windows component while bypassing certain detection and prevention mechanisms.

Suspicious Runscripthelper.exe

This technique leverages Runscripthelper.exe as a trusted Windows binary to execute scripts indirectly, rather than invoking PowerShell or other scripting engines directly.Runscripthelper.exe is part of the operating system and is generally considered benign and rarely scrutinized. By abusing it, an attacker can pass parameters (such as surfacecheck) that cause the binary to execute embedded or referenced scripts behind the scenes. This creates an execution chain where the actual scripting activity is masked behind a legitimate system executable, making it less obvious to both defenders and security controls.

An attacker would use this technique primarily for defense evasion. Many detection mechanisms focus on identifying suspicious parent processes like powershell.exe, cmd.exe, or wscript.exe. By shifting execution to Runscripthelper.exe, the attacker reduces the likelihood of triggering those detections. In environments with application whitelisting or strict execution policies, trusted binaries like this are often allowed by default, enabling the attacker to bypass controls that would otherwise block direct script execution.

Additionally, this approach supports living-off-the-land (LOLBAS) tactics, where attackers avoid dropping custom malware and instead rely on pre-installed tools. This minimizes artifacts on disk, reduces forensic footprint, and blends activity with normal system operations. Because Runscripthelper.exe is not commonly used in everyday workflows, it may also evade behavioral baselines, especially if monitoring rules are not tuned to flag its misuse.

Overall, the technique works by hiding malicious script execution behind a legitimate binary, allowing attackers to run code more stealthily, bypass controls, and complicate detection and investigation.