An independent researcher's lab test finds SAP's Security Audit Log carries no event for OS command execution via SM49/SM69 or RFC, only OS-level auditd sees the command on every path

An independent researcher, publishing on Detect FYI / Medium and syndicated in full via malware.news, demonstrates on a self-owned SAP NetWeaver AS ABAP 7.52 lab that SAP's Security Audit Log (SAL) carries no event type or field for OS-level "external command" execution launched via transactions SM49/SM69 or over RFC, a structural gap in the log's schema, not a misconfiguration that can be turned on (Detect FYI, 2026-09-20). External commands run through the sapxpg helper process as the <sid>adm OS-owner account, and the researcher found that most Linux-applicable SAP-delivered command definitions accept additional runtime parameters, so the binary actually executed at runtime can differ entirely from the one an administrator defined; demonstrated by using a find-with--exec command definition to run /usr/bin/id instead of its intended target. On the interactive SM49 path, the SAL records only a generic "Transaction SM49 started" event, with no command, binary or parameter data, even with every audit class enabled. On the RFC path, the SAL at best records an "RFC call" event naming only the invoked function module (SXPG_COMMAND_EXECUTE), never the command or its arguments. Only the background-job path (SM36) records the full command and its output, and it does so in the job log rather than the Security Audit Log.

OS-level auditd is the only source that sees the full argument vector on every path, via the sapxpg parent-process chain (SAP work process → sapxpg → target binary), but the researcher flags three practical failure modes: the -a task,never audit rule, which some SUSE/SLES builds ship active and others omit entirely, silently suppresses execve auditing for new tasks; runtime auditctl changes do not survive reboot unless persisted under /etc/audit/rules.d/; and a bare execve rule is noisy unless filtered on a ParentImage ending in sapxpg, since that name matches both the SAP work-process binary and the SAP Host Agent's own sapxpg (the latter running as root). Because the SAL always knows the SAP user but never the command, and auditd always knows the command but only the OS account, the researcher recommends bridging the two by time-correlating the SAL's SAP-user timestamp (or, on the background path, simply reading the self-sufficient job log) against the auditd execve record within a tight window to reconstruct the full "this SAP user ran this OS command as <sid>adm" statement.

Triage: a sapxpg child process running a benign, expected command is routine SAP operation and not itself a signal. The researcher's recommended discriminator is content-based: a high-severity alert on any sapxpg-child command line carrying injection gadgets (-exec, an interpreter invocation, shell metacharacters) versus a lower-severity baseline rule matching any sapxpg child regardless of content, to establish what normal looks like in a given environment before tuning the higher-severity rule.