Insights Blog

Mac Forensics: Viewing, Understanding, Deconstructing, and Creating .plist Files – Part 3 of 3

In part one of this blog series, we covered ways a Mac forensic examiner may view .plist files using both Apple and third-party tools. Part two sought to improve .plist file knowledge and discussed how to deconstruct a .plist file and include the most important objects in an examiner report.
Up to this point, we have looked at how an examiner may use artifacts stored in a .plist file to determine historic computer activity. The third and final installment of this .plist file blog series discusses how to create .plist files that perform functions such as launching daemons, scripts, and applications… this is where things get interesting!
Launch Daemons
To work properly, .plist files that launch daemons, scripts, or applications at boot time (system-wide) must be located in one of the Mac OS X launch folders. Machines running the OS X operating system normally have a LaunchDaemons folder and a LaunchAgents folder here:


and here:


Plist files that launch user-specific daemons, scripts, or applications when a user logs into their OS X account, may be placed in this folder:


Creating a .plist File
A user may  define .plist file keys and key values so that an associated process executes once, executes at certain intervals, and/or “stays alive.”  In this example, a custom .plist file named com.watcher.plist has been placed in the ~/Library/LaunchAgents folder so that it ‘loads’ when a specific user logs into their account. The .plist file then executes a shell script, which in this example is located on the logged-in user’s Desktop.
The .plist file contents looks like this:

This com.watcher.plist file has several interesting keys and key values:

KeepAlive – This key is followed by a </true> tag, so if a user quits this process, the process automatically relaunches.

Label – The key value associated with this .plist object, in this case ‘local.watcher,’ is the process name as it would appear in a process list such as an Activity Monitor application process list (if the process is active) or an OS X Terminal application process list (if the process is active or scheduled but currently inactive).

Note that these two .plist keys (KeepAlive and Label) have a single key value associated with them; their relationship is one-to-one. The next ‘ProgramArguments’ .plist key is a little bit different, as there are two key values associated with a single key. One might still consider this a one-to-one relationship, as the .plist key is associated with a single element, the array container. But, recall from part two of this blog series that elements in an array container may be randomly accessed, and an array may contain many elements of any data type. If a single .plist key has more than one element associated with it, these elements are placed in an array container.
The ‘ProgramArguments’ key is followed by the <array> begin tag, two string elements, a ‘/bin/bash’ string and a ‘/Users/<shortname>/Desktop/’ string, and the </array> end tag.

ProgramArguments  – This .plist key defines how, where, and what the launch script executes. In this case, a bash shell launches and executes the shell script located on the currently logged-in user account Desktop (though any ‘stealthy’ location will do).

The next two .plist keys once again have single key values associated with them:

StartInterval – This .plist key causes the associated script to run at a specified time interval expressed in seconds. In this case, the script runs every 600 seconds or ten (10) minutes.

RunAtLoad – This key is followed by a </true> tag. Therefore, the .plist file loads when the user logs into their user account, and the script is immediately executed.

If all of this is clear as mud, and/or you are like us and just MUST know more, we recommend taking a moment to  visit this Apple Developer web page, read the PLIST man(ual) page, and follow the links to additional resources. Or, simply launch the Mac OS X Terminal application and type this at the shell prompt to read the plist man page locally on your own machine:

man plist

Let’s go ahead and look at the script. Because this script is essentially a text file, we can use any text editor to view it:

d=`date +%m%d%y%H%M%S`

mkdir -p ~/Library/private/output/$d
cp /private/var/log/daily.out ~/Library/private/output/$d/
cp /private/var/log/fsck_hfs.log ~/Library/private/output/$d/
cp /private/var/log/install.log ~/Library/private/output/$d/
cp /private/var/log/monthly.out ~/Library/private/output/$d/
cp /private/var/log/secure.log ~/Library/private/output/$d/
cp /private/var/log/ipfw.log ~/Library/private/output/$d/
cp /private/var/log/system.log ~/Library/private/output/$d/
cp /private/var/log/weekly.out ~/Library/private/output/$d/
cp /private/var/log/windowserver.log ~/Library/private/output/$d/
zip -r -q -9 ~/Library/private/output/$ ~/Library/private/output/$d/
rm -r ~/Library/private/output/$d
The first line of code consists of a ‘#!‘ prefix, pronounced “hash bang”  by some and “she-bang” by others! (bang), followed by the script interpreter, in this case the bash shell. The second line defines the variable ‘d’ as the date and time with month, day, year, hour, minute, and seconds. The current local machine date and time is inserted wherever the ‘d’ variable appears in the script.
Next, the script “makes” a directory (mkdir) named $d (the current local machine date and time) in the user’s Library folder, and copies (cp) the log file located along the first path in each line of code to the directory located along the second path in each line of code (in this case, the newly create $d directory).
After all specified log files are copied, the script ‘zips’ or archives (zip -r -q -9) the entire directory to a file located in the same directory as the newly created $d folder.  Lastly, the script deletes the original $d directory and all of the log files contained within so that only the archive file remains (the rm command deletes the directory and the -r option [recursively] deletes all the files in the directory).
Optionally, one could also program the script to secure copy or secure FTP the archive file to another location.
IT security professionals may use this script to monitor unauthorized user activity on a Mac. Forensic examiners and/or incident response professionals might find a similar script running on a compromised machine.
Incident response professionals must make choices about how to best control processes. Processes may be terminated or paused; however, it is essential to understand the concepts described in this blog and to thoroughly understand the process’s purpose and nature before affecting the process.
If a user wished to unload the .plist file in this example, it might be done by launching the OS X Terminal application and typing:

launchctl unload ~/Desktop/com.watcher.plist

The ‘launchctl’ command also allows users to list active AND scheduled, but currently inactive, processes.  To do the latter, launch the OS X Terminal application and type:

launchctl list

A process list appears that includes the numeric process ID (if the process is currently active), and the process name. In this example, the key value ‘local.watcher’(paired with the ‘Label’ key) is listed. Because our local.watcher process is scheduled to run every 600 seconds, it appears in the OS X Terminal process list even if it is currently inactive. If the local.watcher process is currently active, its process ID also displays. If it is not currently active, a process ID does not display.
Conversely, the local.watcher process only appears in the Activity Monitor application process list if the process is currently active. We highly recommend that serious Mac forensic examiners take time to get comfortable with this and other useful OS X Terminal commands. Oftentimes, an investigator may uncover important information using the Terminal application that otherwise may be overlooked.
This concludes our three-part Mac Forensics .plist File blog series. If you feel compelled to take on a solid Mac Forensics challenge, be sure to check out our new Mac and iOS Certified Forensic Examiner (MiCFE) program. If you have any questions about the MiCFE program, please contact anytime.
And as always, we welcome your feedback and suggestions!
Apple, Inc. Mac Developer Library. July 9, 2003. (accessed November 28, 2012).

BlackBag Training Team
Latest posts by BlackBag Training Team (see all)