Nothing matches that yet. Tell us what you were looking for and it goes on the list.
Linux Audit Framework · Event ANOM_ABEND
A program died on a signal rather than exiting normally — most often a segmentation fault. auditd records it without any rule being configured, which makes it the one crash record you can rely on being present on a stock Linux system.
Also written as type=ANOM_ABENDauditd ANOM_ABENDaudit sig=11 SIGSEGVabnormal end audit record
A program crashed. On Linux desktops this is usually a browser tab, a media player, or a graphics driver having a bad day, and the system carries on regardless. It is worth noticing only if the same program crashes over and over.
This is your cheapest exploitation-attempt signal and almost nobody watches it. Memory-corruption attempts against a service overwhelmingly fail before they succeed, and each failure is a SIGSEGV or SIGABRT here. A sequence of ANOM_ABEND records for the same network-facing binary within minutes is worth more attention than most IDS alerts, because it is evidence of something actually reaching the process rather than of a signature matching.
Sanitised. Addresses come from the RFC 5737 documentation ranges.
type=ANOM_ABEND msg=audit(1757251642.915:8331836): auid=4294967295 uid=33 gid=33 ses=4294967295 subj=unconfined pid=24817 comm="nginx" exe="/usr/sbin/nginx" sig=11 res=1Everything else in the log line is context.
11 (SIGSEGV)Segmentation fault — the process touched memory it should not have. The classic result of both a bug and a failed memory-corruption attempt. 6 (SIGABRT)The process aborted itself. On modern builds this is usually a compiler or libc hardening check firing — stack smashing detected, heap corruption, a failed assertion — which means a protection worked. 4 (SIGILL)Illegal instruction. Execution reached something that is not code, which is a strong indicator of corrupted control flow. 7 / 10 (SIGBUS)Bus error, often a misaligned access or a truncated memory-mapped file. 9 (SIGKILL)Killed outright. Usually the OOM killer or an administrator rather than a fault. Most of the time it is one of these.
What gives it awaySeveral ANOM_ABEND records for the same daemon within a short window, especially with sig=11 or sig=4, and connection logs showing the same remote source across all of them.
ATT&CK T1190What gives it awayRepeated crashes of a setuid program under a single non-root auid, at machine speed rather than human speed.
ATT&CK T1068What gives it awayA run of sig=6 SIGABRT records from the same binary. The abort is the protection succeeding, and the repetition is what tells you something kept trying.
ATT&CK T1190ausearch -m ANOM_ABEND -ts today -iausearch -m ANOM_ABEND -ts recent -i | grep -oP 'exe=\S+' | sort | uniq -c | sort -rnausearch -m ANOM_ABEND -ts today --raw | grep 'sig=11' | grep -E 'exe="/usr/sbin/(sshd|nginx|httpd|postfix)'coredumpctl list --since todayA process terminated abnormally — it was killed by a signal rather than exiting on its own. The audit framework writes this record without any audit rule being configured, which is unusual and useful: it means crash records exist on stock systems where nobody has set up auditing at all. The `sig=` field says which signal, and 11 (segmentation fault) is by far the most common.
Not by itself — programs crash for ordinary reasons all the time. What raises it is the pattern: the same network-facing daemon crashing several times in a short window, with the same signal, is what a failed memory-corruption attempt looks like from the outside. Attacks of that kind fail far more often than they succeed, and the failures are visible here before the success is visible anywhere.
Signal 11 is SIGSEGV, a segmentation fault: the process accessed memory it had no right to. Signal 6 is SIGABRT, which normally means the program deliberately killed itself because an internal check failed — a stack protector detecting a smashed stack, glibc detecting heap corruption, or an assertion failing. A SIGABRT is often a hardening control working correctly, and repeated ones mean something kept triggering it.
`ausearch -m ANOM_ABEND -ts today -i` lists them with names resolved; the `exe=` field gives the real binary path, which is more trustworthy than `comm=` because comm is truncated at fifteen characters and can be set by the process. For deeper analysis you need a core dump, and on systemd systems `coredumpctl list` will show whether one was captured.
Last reviewed 7 September 2026