Shell built-in commands not captured via Auditd Manager

Elastic Stack Elastic Agent
, ,
1

Hello,

I have both required integrations installed — Auditd Manager and Elastic Defend (Data Collection mode) — and I'm using them to support rules like "Tampering of Shell Command-Line History."

For Auditd Manager:

  • I’ve enabled session data.

For Elastic Defend:

  • I’ve enabled “Collect session data” and “Capture terminal output.”

However, built-in shell commands (like history -c) are not being logged. Only direct binary executions are captured (e.g., truncate -s0 .bash_history does trigger the rule).

The rule partially triggers, but shell built-ins like history -c or echo do not generate any events. I assume this is because they don’t invoke a syscall like execve, but I expected the session or terminal capture features to handle that.

Is there anything I’m missing or any additional configuration needed to log built-in commands and trigger these rules completely?

Thank you!

2

Hello,

Both Auditd manager and Elastic Defend do not support capturing shell builtins.

You're correct that auditd and Elastic Defend watch syscalls. Shell builtins are internal functions of shells, and do not call syscalls directly, so they are not visible to these products.

Syscalls which are triggered by builtins can be captured though. For example, a file read syscall triggered by a builtin cat can be logged.

Since syscalls which modify the system state are more important to security, and to capture builtins would require inspecting the internal state of shell processes, which would require custom work for each shell type and version, there are no plans to add support for capturing builtins.

3

Thank you for the detailed response and clarification.

I understand now that shell built-ins (like history -c, export, etc.) are not captured by Auditd or Elastic Defend since they don’t invoke syscalls like execve. However, I noticed that the built-in rule “Tampering of Shell Command-Line History” still includes these built-ins in its logic.

Since these conditions will never trigger under current integrations, I assume they're included for completeness or potential future capabilities.

Also, I understand Elastic doesn’t currently support native integration for tools like pam_tty_audit or tlog, but if there are any recommended methods or third-party setups to supplement this detection gap — especially for terminal input capture — I’d appreciate any suggestions.

Thanks again for the support and great work on the platform.

4

Suggestion: Bash can send to syslog , might need patching / rebuilt, logstash (or probably beats too) can read from syslog and output to elasticsearch.

5

Thanks for the suggestion!
Bash can log to syslog, and the Elastic Agent’s System integration can pick that up directly — no need for Beats or Logstash. We just add a simple logger command to .bashrc, and Elastic handles the rest.