Beyond the good ol' LaunchAgents - 31 - BSM audit framework
This is part 31 in the series of “Beyond the good ol’ LaunchAgents”, where I try to collect various persistence techniques for macOS. For more background check the introduction.
macOS implements the OpenBSM audit framework created by McAfee, which allows someone to audit system events, like login, file access, etc… This has been part of the system for very long time. Auditing has several components, the main one being the kernel, which handles all the events. The main user mode process is auditd
, which is mainly responsible for logging. It’s a huge framework, detailed very well by Jonathan Levin in his *OS Internal Part 3
book. I suggest reading that part, but you can also find some information here:
auditd
can be configured via various files, which are located at /etc/security/
. The logs can be found under /private/var/audit/
, but they are not important for us now.
max:~ root# ls -l /etc/security/
total 48
-r--r--r-- 1 root wheel 652 May 13 00:29 audit_class
-r-------- 1 root wheel 358 May 13 00:29 audit_control
-r--r--r-- 1 root wheel 26649 May 13 00:29 audit_event
-r-------- 1 root wheel 77 May 13 00:29 audit_user
-r-xr-xr-x 1 root wheel 1326 May 13 00:29 audit_warn
audit_control
is the main configuration file, by default it configures auditd
to log login and authentication events. The file which is interesting for us is audit_warn
. It’s a shell script, that is executed when an audit warning occurs.
max:~ root# cat /etc/security/audit_warn
#!/bin/sh
#
...
As root, we can edit this file, let’s add the following.
touch /tmp/createdbyauditd.txt
We can manually trigger a warning by forcing a log rotation by running the sudo audit -n
command.
Then our file will be created.
Detection Consideration Link to heading
The most trivial way to detect this persistence is monitoring file modification of audit_warn
.
Additionally the process tree when our command is executed will look like the following:
auditd
-->/bin/sh
---->touch (or any command specified in the script)
Note, that the main interpreter can be also changed from #!/bin/sh
to anything else, so other child processes can be suspicious as well.