logs

Analysis of Apple Unified Logs: Quarantine Edition [Entry 6] – Working From Home? Remote Logins

I’m sure many of us are working remote right now possibly using some of these remote capabilities. Remote Logins can include a few different services; SSH and Screen Sharing are two that I’ll show here. These services are disabled by default and would need to be turned on in the user’s Sharing preferences.

When Remote Login is turned on in the Sharing preferences, the system will have an SSH server enabled. Let’s take a look at what an incoming SSH connection might look like first for a user account on the system that does not have this option turned on (janedoe). We are looking for the entries for the process ‘sshd’.

log show --predicate 'process = "sshd"'

One entry to key in on is the “user account has expired”. A user attempted to use SSH to login to this system using the ‘janedoe’ account coming from IP 192.168.1.170, however the connection failed.

Now on a system that does have remote login turned on. This first example shows an incorrect password attempt.

And a correct password attempt and login.

Connections can of course be incoming or outgoing. If the user were trying to access another system it might look like this. Not a whole lot unfortunately.

log show --info --predicate 'process = "ssh" or eventMessage contains "ssh"'

…and when the connection closes.

Screen Sharing is another service that needs to be explicitly enabled in the Sharing preferences. Incoming connections will show the user who logged in and where they came from. The example below shows an incorrect password that failed, and another that was correct. I’ve only queried for messages that contain the text ‘Authentication:’. Looking for all messages associated with the ‘screensharingd’ process will be quite verbose with some metadata about the session. 

log show --predicate 'process = "screensharingd" and eventMessage contains "Authentication:"'

Outgoing connections, like incoming connections, can be verbose. The process is ‘Screen Sharing’ like the application name.

log show --info --predicate 'process = "Screen Sharing"'

I might do a specific filter for ‘connect’ and ‘disconnect’ in the messages to see multiple sessions over time.

Analysis of Apple Unified Logs: Quarantine Edition [Entry 3] – Playing in the Sandbox, Enumerating Files and Directories

While I’ve been researching various queries with these unified logs, I’ve noticed some peculiar but forensically useful entries. I have found many of these entries to be created when I’m browsing directories via Finder. However, they don’t appear to be logged on every directory I browse. Many of these entries also appear to be associated with particular applications/services.

This query is searching for the ‘kernel’ in the process path and ‘Sandbox’ in the sender path. To filter even further, I’ve added a keyword search for ‘file-read-xattr’ in the event message area. 

This query limits the search to the last 10 minutes and during my testing these are directories I specifically browsed to within Finder. Again, I’ll note that I was able to browse to other directories using Finder but these were not logged for whatever reason.

log show --last 10m --predicate 'processImagePath contains "kernel" and senderImagePath contains "Sandbox" and eventMessage contains "file-read-xattr"'

This first example shows entries associated with the ‘garcon’ process which is associated with DropBox. I’m using TaskExplorer here from Objective-See to review information about this process.

These entries are not specific to Dropbox. Looking at my own logs, I also have entries for other applications and system services:

  • App Store

  • Microsoft Excel

  • Microsoft Word

  • MusicCacheExtens[ion] (Long process names get truncated)

  • TVCacheExtension

  • TextEdit

  • com.apple.CloudP[hotosConfiguration?]

  • mediaanalysisd

To look for the Microsoft specific entries, I added another keyword to the query to search the message area for ‘Microsoft’. This should cover all Microsoft products. While the listed directories were directories I recall browsing to, some of these documents I did not specifically open (over and over again) at these times. The application may somehow cache some of these document paths. I did in fact open these documents, just not during these particular times.

log show --predicate 'processImagePath contains "kernel" and senderImagePath contains "Sandbox" and eventMessage contains "file-read-xattr" and eventMessage contains "Microsoft"'

The last example shows TextEdit entries. This may look like I opened or accessed this Zoom chat transcript three times today (4/23/2020), but I sure didn’t. I did however open it up in the past. Again, this appears to be cached somewhere to make it appear that it has been opened.

log show --last 10h --predicate 'processImagePath contains "kernel" and senderImagePath contains "Sandbox" and eventMessage contains "file-read-xattr" and eventMessage contains "TextEdit"'

These entries certainly need to be researched further. Some entries appear to be associated with specific user interactions while others seem to be logged at random due to how an application may work. It is worth noting these entries are a log type of ‘Error’. They may not always be available. (Some are of type ‘Default’ as well).

While the timestamps may not quite match up to specific usage, these entries may still be useful in investigations to show directory contents or documents previously opened.

Analysis of Apple Unified Logs: Quarantine Edition [Entry 2] – sudo make me a sandwich

sandwich.png

The first item in the Unified Logs we will take a look at is a relatively simple one – evidence of the ‘sudo’ command.

In this example I’m attempting to view all the log types (including default and info) for the last day (--last 1d). The search/filter (--predicate) I’m using is looking for the ‘sudo’ process. This column highlighted in pink text.

log show --info --debug --last 1d --predicate 'process == "sudo"'

This has many entries not immediately useful to me, I can create a more specific query to filter the noise out. I’ve removed the arguments for debug and info messages as they do not appear to be needed for this query (they may for others so don’t forget about them!). To get just the entries of interest, I added a keyword search for ‘TTY=’ in the message column (eventMessage).

log show --last 1d --predicate 'process == "sudo" and eventMessage contains "TTY="'

Another technique to look at just the entries associated with a specific use of ‘sudo’ can be to filter by the Process ID (PID) by using ‘processID’. (I replaced info/debug message in the query not because its necessary but purely because its muscle memory for me to do so!)

log show --info --debug --last 1d --predicate 'processID == 26220

I tried to get a bit creative with ‘sudo’, so I incorrectly put a password in (twice) while trying to use ‘sudo -s’. I then put in the correct password. Note, I’m using the ‘last’ argument to only look at events in the last 20 minutes. Very useful if you are trying to research a certain scenario without having to scroll through millions of log entries!

log show --last 20m --info --debug --predicate 'process == "sudo" and eventMessage contains "TTY="'

While we’re here, it would be a shame not to take a quick look at ‘su’ as well. Oops, looks like I got the password wrong while doing a ‘su janedoe’ three times before finally getting it right.

I’ve changed this query a tiny bit. The process was changed to ‘su’ instead of ‘sudo’ and the keyword in the message from changed from ‘TTY=’ to ‘tty’ to capture these entries.

log show --last 20m --info --debug --predicate 'process == "su" and eventMessage contains "tty"'

Finally let’s get a query to find all the relevant ‘sudo’ and ‘su’ commands. I created a slightly more complex query that combines searching for two different processes (sudo and su) while still filtering for ‘tty’ in the message.

log show --last 20m --info --debug --predicate '(process == "su" or process == "sudo") and eventMessage contains "tty"'

To make query slicker , we can use ‘beginswith’ to just look for ‘su’ in the two processes.

log show --last 30m --info --debug --predicate 'process beginswith "su" and eventMessage contains "tty"'

And one last one, because I know you NEED to know!

incident.png

Big thanks to one of my favorite comics for the classic content, these never get old! XKCD by Randall Munroe