Indirect Command Execution

Indirect command execution shows up after initial access, typically as the first local-execution step following a phishing attachment, a malicious shortcut, or an exploited document. It is a delivery and evasion technique, not an objective on its own: the attacker's real goal is whatever pcalua or forfiles launches next, usually a PowerShell downloader, a script that fetches a second stage, or a dropped binary that establishes persistence.

It sits alongside other Defense Evasion techniques the same intrusion typically uses, most often Signed Binary Proxy Execution (T1218) for the next hop and Obfuscated Files or Information (T1027) to hide the payload the launcher is calling. Because the technique's entire purpose is bypassing command-line restrictions, it is disproportionately common in environments running application allow-listing or command-line logging policies that block cmd.exe and powershell.exe outright: attackers reach for forfiles or pcalua specifically because those controls do not cover them, which is itself a useful triage signal when the rule fires in a hardened environment.

Forfiles has legitimate batch-processing uses, IT scripts that loop over log files, backup jobs that clean up old exports, or software deployment tooling that touches files matching a pattern. Pcalua.exe genuinely does run when a user right-clicks an older application and selects 'Troubleshoot compatibility', which some organizations' help desks still walk end users through for legacy line-of-business software.

The differentiator is the command target and its parent. Forfiles used by a scheduled maintenance task calling a known internal script from an approved path is routine; the same forfiles /c syntax spawning powershell -enc from a user's Temp folder, with no ticket and no prior history on that host, is not. Build a short allow-list of the specific scripts and service accounts your environment legitimately uses forfiles for, then alert on any invocation outside that set. For pcalua, baseline which applications your users actually run through the compatibility wizard; a first-time pcalua -a target pointing at an executable in a Downloads or Public folder is the pattern worth escalating, not the tool itself.

When this fires, start with the target: what did forfiles or pcalua actually launch. Pull the full command line, not just the alert summary, since the payload is usually base64-encoded PowerShell or a path to a dropped file. Check the parent process too: a scheduled task or explorer.exe launching the LOLBIN from a user-writable path (Temp, Downloads, Public) is a much stronger signal than the same launcher running from System32 under a known service account.

If the target is an unrecognized script or binary with no legitimate business justification, treat it as active execution, not reconnaissance. Isolate the host, capture the dropped file and any child processes it spawned for analysis, and check for what came immediately after: new scheduled tasks, registry Run key writes, or an outbound connection, since indirect execution is almost always followed within seconds by the real persistence or C2 step. Escalate to full incident response if the host shows any of those follow-on indicators rather than waiting for a second alert to confirm.