Incident Response With TrueTree
Download TrueTree
Incident Response With TrueTree
TrueTree is an open-source tool designed by me for threat hunters, incident responders, or anyone in between. If you read part one of this blog post, you know that nearly all processes on MacOS end up getting shown as a child of launchd due to Apple’s unique XPC behavior. TrueTree works by collecting additional pid information from the system instead of just the standard pid and ppid. When executed, it displays a process tree laid out in what I believe to be the most useful format using all process ids and plists discussed in the previous blog post. In this blog post we’ll take a look at some different trees produced by the TrueTree tool.
In this blog post we’ll take a look at some different trees produced by the TrueTree tool.
Dock, Spotlight, and Finder
When you open an application from the Dock, Spotlight, or Finder, each new application will show as a parent under the launchd process. On the other hand, TrueTree will show us which programs were opened accordingly. In the below screenshot you can see that I’ve opened Keynote.app, Messages.app, and Mail.app all using the macOS Dock at the side (or bottom) of the Desktop screen. Furthermore, you can see that the Dock application is actually created at the request of /System/Library/LaunchAgents/com.apple.Dock.plist.
Likewise, we can see all applications that were opened by using spotlight functionality (cmd+space and typing in an app name). Below we see that Spotlight was used to open Calendar.app as well as Xcode.app.
Finally we can see all applications that were opened by double-clicking them in Finder.app. In my case it appears I opened Calculator.app and was previewing a document with Preview.app.
LoginWindow
Launchd is responsible for going through each application that was closed at shutdown and ensuring that they get started again when the system boots back up. It does this by going through the plist items in “~/Library/Preferences/ByHost” (credit: https://www.virusbulletin.com/uploads/pdf/conference/vb2014/VB2014-Wardle.pdf) and opening them accordingly. We can view these programs by looking at the children of the LoginWindow process, thanks to the “submitted by” pid.
Open and AppleScript
As mentioned in part one of this blog post, sometimes we end up with a “submitted by” parent that has already terminated and we are no longer able to get details other than the pid and process name. Still, this is often valuable information and therefore still used by TrueTree. Two real world examples often used by malware are the “open” command and Apple Scripts. Calling the open command to run a program or application results in a new child created under launchd when looking at standard pids and ppids. The open command then disappears as if it never happened. Yet the submitted by pid reveals that it was the reason for execution.
Above we see the open command was used to open Safari. The same applies if we request Safari to be opened by an AppleScript.
These are just two of many different scenarios that may lead to a dead submitted by parent.
Exec'ed Processes Managed by Launchd
Although rare, sometimes processes managed by launchd will call exec() without forking which leaves us an extra process path we can report even though it’s no longer running. A simple example of this can be seen when TrueTree runs while someone is logged in via ssh.
In the above image we can see that before /usr/sbin/sshd was running as pid 55586 it was sshd-keygen-wrapper. This is due to sshd-keygen-wrapper calling exec() without calling fork(), leaving us with a small forensic tidbit.
Office Macros
Oddly enough, the behaviors of Microsoft Office macros also result in child processes under launchd. However, thanks to the responsible pid field we can correlate the executed commands back to the Microsoft Office application they came from. Take the resulting tree below from a macro that spawned a Python reverse shell connection.
Here we can see that I used Finder to open a malicious Excel document that spawned a Python process. Let’s take a look at the result if I were to open the document under Mail.app which is a bit more accurate to what a true phishing attempt might look like.
In the above screenshot we don’t actually see Mail.app play a part in the tree that led to the Python execution. CoreServicesAgentUI ends up opening the Excel document instead. CoreServicesAgentUI has many different responsibilities on macOS. One of these roles is to handle the actions of various pop-ups on the system by launching new executables based on user interaction. It appears that Mail.app is able to communicate with it to display and open the different attachments stored in an email. From the testing I’ve done, if you see CoreServicesAgentUI used in a tree the odds are good that either something was opened through a prompt (Allow prompt, open prompt, yes or no prompt, etc.) or was opened via another Apple application (see Scott Knight’s awesome writeup on CoreServicesAgentUI for more details). We can try one last way of finding the true origin of this Excel instance by searching for other processes created around the same time as the Excel process. I often do this by searching for processes created at the same minute of the one I’m interested in.
The above screenshot shows me using iTerm’s cmd+f to search for all the occurrences of the time when the Excel program ran (2020-02-11 15:14). I see that roughly 20 seconds before Excel was opened, a number of com.apple.WebKit.WebContent processes were created under Mail.app. Safari, Mail, and many other applications use this process. In my case, they were created when I double clicked on an email to view it. You might not always get lucky like I did here. It will depend on if the user has closed the malicious email or closed mail.app altogether.
Custom URL Schemes
Custom url schemes allow one application to reference another application by using a specific string. From a malicious standpoint the Windtail malware is most commonly referenced. It operates by convincing a user to download an application. After that application is downloaded it is automatically unzipped and registered by the operating system while the website redirects to a custom url scheme that then opens the application without having to rely on the user to click it. We can test what this process tree would look like by opening a man page from Safari. This is possible because the Terminal.app defines a custom url scheme in its info.plist in the format of “x-man-page://<command>”.
Now we can go find Terminal.app inside of the TrueTree output. Keep in mind that according to the basic pid and ppid process tree this Terminal was created by launchd.
When the custom url scheme is used we see that once again the executed application (Terminal.app) was created under CoreServicesUIAgent just like the Excel document opened from Mail.app. This makes sense since we have clicked the Safari “Allow” prompt to open the Terminal. It’s unfortunate that we’re left with no way to connect this application execution directly to Safari, but given that it spawned from CoreServicesUIAgent we can make the assumption that it likely was opened by another application developed by Apple.
When opening a url scheme from a non-Apple based program such as Google Chrome we see the resulting tree is much closer to what we’d expect.
Office Macro Reverse Shell Delivered via CustomUrlScheme
In the interest of driving home why it’s important to have a reliable process tree, I will bring the last two use cases together to show what happens when a user is tricked into running a custom url scheme that opens an Office document containing macros. I use Office Maacros as an example because their frequency and simplicity make it a good demo scenario.
Microsoft Office provides a CustomURLScheme that lets a user define a remote document to be downloaded and automatically be opened within a corresponding Office software product. Let’s assume that a victim user gets tricked into opening a url scheme for a remote Excel document (I’ll use Python SimpleHTTPServer to serve up a document on my localhost). The url scheme to get a user to do this would look like so…
If the user chooses to open the Excel document they are then greeted by an Office prompt asking them if they want to enable macros.
If the user agrees to enable macros a Python backdoor is executed in the background, ultimately revealing the following process tree.
Thanks to all the different pids TrueTree collects we’re able to build a process tree that tells a story of what actually happened. Google Chrome ran Microsoft Excel which then ran something written in Python. This smells like something incredibly malicious. If we were to use standard process ids such as those provided by the “ps” command we would see all of these same processes running; however, they would all be running under the launchd service, providing us with no way of knowing that they were all connected in some way.
Conclusion
In security we need every advantage we can get. Looking at processes to determine what is suspicious is incredibly difficult with the standard pids provided on macOS. Above we discussed just a few different examples where using the TrueTree concept gives us insight into how the system behaves in different scenarios. Sometimes malware can even be discovered simply by viewing processes created at the request of launch agents and daemons. Other times it may require a deeper understanding of Apple processes and their role in the operating system.
