HTB Sherlock: Gatekeeper
Post-compromise analysis of a MacOS
Sherlock Scenario: Wika is a highly motivated pre-sales engineer dedicated to achieving his professional goals. To ensure his success, he carefully selected the best tools and applications to streamline his workflow. However, an unknown adversary was actively working against him, attempting to sabotage his efforts and block him from reaching his targets.
Unfortunately, Wika’s systems were compromised, putting his progress at risk. In response, we secured his Mac device for a detailed forensic investigation to gather evidence and uncover the truth. We need your expertise as a DFIR analyst to investigate the incident.
https://labs.hackthebox.com/achievement/sherlock/950755/951
Links:
Investigation summary:
This investigation followed a compromise of a Mac machine owned by Wikas. I was unable to identify the root cause of the initial access, but my current guess is the exploitation of the apache service that was running on this asset. This estimation is based on the running services on this asset as well as the TTPs observed.
The attack chain included initial access via a reverse shell, followed by immediate local enumeration activities including whoami and sw_vers. We then see some exfiltration of a text file from the user’s desktop to bashupload.com via the curl command.
Then see the ingress of attacker tooling, specifically a local privilege exploit (LPE) targeting TimeMachine (tdiagnose). This particular exploit is also widely available and is included in the Metasploit toolkit, indicating that there is likely a meterpreter shell running. We also see a successful bypass of Gatekeeper for a malicious application, although the source and purpose of this application is currently unknown.
After the attackers escalated to the root user, they moved to remove evidence of their presence. Including the deletion of payloads and clearing of bash history.
The attack chain stops there as far as I have been able to find, although some notable mentions include that the System Integrity Protection (SIP) had been disabled and there were no alerts within the XProtect service.
Indicators of compromise:
+------------------+------------+-------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------+
| NAME | CONFIRMED? | IOC TYPE | DESCRIPTION | LOG |
+------------------+------------+-------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------+
| Funphotos.gz | Yes | Gzip archive | This was a gzip containing the Funphotos.app, it appears the creation and download of this archive was an attempt to bypass Gatekeeper's notary checks via exploitation of CVE-2022-22616 by hosting and re-downloading this archive on the local-host. | com.apple.launchservices.quarantineeventsv2 |
| Funphotos.app | Yes | MacOS Application | This was a malicious MacOS Application installed by the TA during the execution phase of their attack. | Full-file listing.txt |
| priv.zip | Yes | Zip archive | This was an archive containing a MacOS local privilege escalation payload targeting CVE-2019-8513. | Bash history, FSEVents, UAL |
| test | Yes | Mach-O executable | This was the LPE payload. | Bash history, FSEvents |
| 192.168.1.2:8000 | Yes | IP Address | This was the address/port used to ingress the priv.zip archive containing LPE payload. | Bash history |
| bashupload.com | Yes | Domain | This is a legitimate service that was abused to exfiltrate mytarget.txt and Targets.rtf. | Bash history |
| <redacted.txt> | Yes | File | File egressed to bashupload.com. | Bash history |
| <redacted.rtf> | Yes | File | File removed by attacker, no additional context. | Bash history |
+------------------+------------+-------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------+
Setup and evidence parsing:
After downloading the evidence from the challenge portal and unzipping with the password hacktheblue we will see the following directory listing:
Wikas Mac evidence:
In order to effectively make use of some of these artifacts we need to make use of some parsing and converting tools. We will primarily use UAL Parser, FSEventsParser and plutil.
We will start with UAL Parser as the Unified-Audit Log is probably the most useful artifact when investigating a MacOS endpoint. Right now the best tool for parsing this artifact is the one made by Mandiant, however one downside to this parser is that it only exports the data to a CSV or JSON so you either need access to excel, transfer to a Windows host or convert to DB. I would recommend either transferring the files to a Windows host with Eric Zimmerman’s Timeline Explorer tool OR convert the CSV to a DB for native investigation with DBViewer. This is because the UAL is a pretty beefy file and triage with timeline explorer or dbviewer will be much faster!
Using UAL parser (I am assuming you know how to download a file ;)):
./unifiedlog_iterator -m log-archive -i /Volumes/Evidence/wikas-mac_20250204_022610/LiveResponseData/CopiedFiles/Logs/UnifiedLogs/wikas-mac_20250204_022610.logarchive -o /Volumes/Evidence/UAL-Parsed -f csv
There is another log archive present in the collected evidence which could be helpful so lets also parse that:
./unifiedlog_iterator -m log-archive -i /Volumes/Evidence/wikas-mac_20250204_022610/LiveResponseData/BasicInfo/brctl/system_logs.logarchive.logarchive -o /Volumes/Evidence/Syslog-Parsed -f csv
After we have our logarchives all parsed and usable, we can start parsing the FSEvents logs present in this collection. FSEvents are a super valuable MacOS forensic resource, they are similar to the $USNJrnl in Windows.
To parse these we are going to use the FSEvents parser provided above by David Cowen. We are not going to just parse these logs, we’re also going to add some of the helpful queries that David provides as part of the FSEvents parser project as additional tables.
Using FSEventsParser (If you can’t see the log in Finder, use command+shift+.):
python3 FSEParser_v4.0.py -s /Volumes/Evidence/wikas-mac_20250204_022610/LiveResponseData/CopiedFiles/fsevents/.fseventsd -t folder -o /Volumes/Evidence/FSE_Wikas -q report_queries.json
Plutil is a built-in Apple utility to convert binary property list files (plist) to a human-readable XML. I didn’t document each time I used this but I did convert a good number of them — very few were actually useful but such is life.
plutil -convert xml1 target.plist
Gatekeeper Lab:
Now we have our evidence looking all pretty we can start looking at the challenge. Although we have parsed out these artifacts we will also need to be cross-referencing and validating findings with some of the other evidence that had been captured.
- What is the macOS version:
This is a nice and easy one to kick things off, if we take a look at the collected evidence there will be a text file that contains this information.
2. What is the full path of the malicious application?
For this question I spent much of my time looking in the parsed FSEvents logs because why wouldn’t you? But that was a massive waste of time and is at least the 3rd time FSEvents have let me down :’).
In the collected evidence, there is a full file listing artifact containing, well… I used this artifact and grepped out all applications with the following search:
grep "^/Applications" Full_file_listing.txt > ExtractedApplications.txt
Then with this extract I went to CyberChef and focused only on unique entries that ended in .app . Reviewing these entries and only one really stood out to me…
3. What is the inode number of the above malicious application?
WHY DOES FSEVENTS NOT HAVE THIS APPLICATION TRACKED!? IS IT NOT A FILE SYSTEM EVENT!? IT DOES NOT MAKE ANY SENSE WHY THE ONE FORENSIC ARTIFACT THAT IS EXPLICITLY MEANT TO TRACK THIS ARTIFACT DOES NOT IN-FACT TRACK THIS ONE KEY FILE — I WANT TO LOVE FSEVENTS SO BADLY BUT IT KEEPS FAILING AT ITS ONE JOB AND HAD ME TROUBLESHOOTING PHANTOM ISSUES, I EVEN LEARNED HOW TO MANUALLY DECODE RAW FSEVENT FILES JUST FOR IT TO SPIT IN MY FACE AGAIN.
If you wanted to learn how to read raw FSEVENTS yourself (I DON’T KNOW WHY YOU’D BOTHER) there’s a really great resource here: https://hackmd.io/@M4shl3/FSEvents.
Anyways, rant over, I’m sure FSEVENTS will eventually be of some use to me. To answer this file we need to look in a previously unknown to me resource which is brctl. brctl diagnose was used to collect the diagnostic logs for the ‘Manage the CloudDocs daemon’. Within this export of logs there is a file detailing information on registers. Reviewing this file shows a number of instances of the funphotos app, some of which show that one incarnation of the file was as a gzip as well as potential initial paths.
4. In the execution phase, the user executed the application without any restrictions, what is the CVE the attacker tried to abuse to bypass the gatekeeper?
This was a challenging question for me as there have been so many GateKeeper bypass CVEs released on and since MacOS High Sierra. This was compounded by the fact that the UAL only had one entry that contained the string ‘funphotos’ :D.
In order to figure this out I had to take a step back and focus on what Gatekeeper aims to do, how it does it, and correlate that with the information I already had about the malicious app; then finally a bit of research into Gatekeeper bypasses since High Sierra.
I knew that:
The app was called Funphotos.
There was another instance of this filename as gzip.
The path of the gzip was in the Downloads directory.
Gatekeeper prevents potentially malicious external applications from being executed.
We have already established that FSEVENTS will be no use to us for all things this app, so lets go looking in the Safari evidence that was collected! We see there is a history db file, lets pop it open it will surely there should be download events here right!?
Nope :D
So, let’s take a step back, when files are downloaded from the internet how does MacOS know that that’s where they come from? Windows uses ADS ZoneIdentifiers and MacOS has a similar system with extended attributes (XATTR), specifically the Quarantine attribute. I couldn't find quarantine/gatekeeper events in UAL… but I did notice a QuarantineEventsV2 log file in the copied files for Wika.
My file might look a bit different to yours, I was manually editing it to make it a bit more readable. Don’t bother opening this in DBViewer as the file is busted, but catting it out will show you the contents!
Even though the lying Safari DB didn’t have any downloads logged, we can see clearly we have entries for funphotos.gz as well as entries for Xcode!!
This took me way too long to the point where I re-downloaded and parsed the evidence with different tools on three separate days and tried about 30 random CVEs for Gatekeeper bypass.
Finally
If you take another look at the entries here, we can see that there are several instances of funphotos.gz being downloaded from local host on port 8000. If we think back to the goal of this being to bypass Gatekeeper, we can focus our vulnerability research into looking for Gatekeeper bypasses that are specifically related to Safari and/or ‘downloading’ files from local host.
5. At what timestamp did the reverse shell activity begin?
This one wasn’t too bad; you can filter for processes in the parsed UAL output. Tip: To find the correct entry, think of how a reverse shell works.
6. After the user assists in executing the application, what is the first command the attacker runs upon gaining a reverse shell?
This is another nice one that you could probably make a very good guess for. But to find the answer, check out the bash history file ;).
7. What is the name of the malicious archive file the attacker downloads to the system?
The bash history file has pretty much every command issued by the attacker in the first reverse shell.
8. At what time did the attacker compile the exploit?
This one takes a combination of the bash history review to see how/what compiler was used and why. Then armed with this information, some filtering in the parsed UAL logs!
9. When did the attacker get the root shell on the system?
The best way to identify this is to use the bash history file to track the name of the LPE file and then filter for this in the UAL to get the time!
10. What volume name was created during the privilege escalation attack?
After you have identified the name of the exploit and have checked the associated logs in UAL, do some research on the unique aspects you see. This research should be allow you to trace your way back to the exploit code and give you information on the vulnerability that was exploited.
When you know the vulnerability, read up on the exploit and how it works. This will lead you directly to the name of the disk :).
11. An error file was generated during exploitation, indicating a vulnerability in a macOS binary. What is the CVE identifier associated with this privilege escalation vulnerability?
See question 10.
12. According to the MITRE ATT&CK framework, what is the attack technique classification for the injection?
Using the knowledge above, check out MITRE for what best aligns with the exploit.
13. What command was used by the attacker to erase their traces?
The bash history shows us that the attacker swapped to the root user. You can use this information and some clever filters in the UAL to see what privileged commands the user ran as root.
14. At what time did the attacker start erasing their traces?
Timestamp for the event in question 13.
15. What are the names of the 2 files the attacker deleted to prevent the user from achieving his target (in alphebetical order)?
This is found in the bash history file.
16. Meanwhile, he discovered that he might be compromised. What is the search query he conducted to confirm or investigate this suspicion?
Its one of the only useful things found in the Safari evidence!
