# Shell built-in commands not captured via Auditd Manager **URL:** \ **Category:** Elastic Agent\ **Tags:** elastic-stack-monitoring, elastic-stack-alerting, fleet\ **Created:** [May 18, 2025, 6:51am UTC](https://discuss.elastic.co/t/shell-built-in-commands-not-captured-via-auditd-manager/378264 "2025-05-18T06:51:12Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![saretawa5](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/saretawa5/32/143175_2.png) [@saretawa5](https://discuss.elastic.co/u/saretawa5)\ **Post date:** [May 18, 2025, 6:51am UTC](https://discuss.elastic.co/t/shell-built-in-commands-not-captured-via-auditd-manager/378264/1 "2025-05-18T06:51:13Z")
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! ---
**Author:** ![Michael\_Wolf](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/michael_wolf/32/140349_2.png) [@Michael\_Wolf](https://discuss.elastic.co/u/Michael_Wolf)\ **Post date:** [May 21, 2025, 6:09pm UTC](https://discuss.elastic.co/t/shell-built-in-commands-not-captured-via-auditd-manager/378264/2 "2025-05-21T18:09:39Z")
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. ---
**Author:** ![saretawa5](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/saretawa5/32/143175_2.png) [@saretawa5](https://discuss.elastic.co/u/saretawa5)\ **Post date:** [May 21, 2025, 7:24pm UTC](https://discuss.elastic.co/t/shell-built-in-commands-not-captured-via-auditd-manager/378264/3 "2025-05-21T19:24:27Z")
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. ---
**Author:** ![RainTown](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/raintown/32/140206_2.png) [@RainTown](https://discuss.elastic.co/u/RainTown)\ **Post date:** [May 21, 2025, 9:53pm UTC](https://discuss.elastic.co/t/shell-built-in-commands-not-captured-via-auditd-manager/378264/4 "2025-05-21T21:53:29Z")
Suggestion: Bash can send to syslog , might need patching / rebuilt, logstash (or probably beats too) can read from syslog and output to elasticsearch. ---
**Author:** ![saretawa5](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/saretawa5/32/143175_2.png) [@saretawa5](https://discuss.elastic.co/u/saretawa5)\ **Post date:** [May 22, 2025, 12:17pm UTC](https://discuss.elastic.co/t/shell-built-in-commands-not-captured-via-auditd-manager/378264/5 "2025-05-22T12:17:53Z")
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.