Would you know if you'd been hacked?

Added: 2026-05-12

[00:00:00]Take a look at the following two iPhones. How would you be able to tell which one has been compromised with sophisticated spyware and which one hasn't? iOS exploits are designed to be as silent as possible, leaving ideally no visible indication of compromise on a victim's phone. And the implant programs that get installed in the background are completely invisible to the user, but are capable of harvesting data from the phone and shipping it off to an attacker's server all completely silently and in the background. The closed nature of iOS makes it quite difficult to investigate what's going on behind the scenes on the system and as a consequence it can be very difficult to observe indications of compromise on an infected iPhone. We don't have access to a list of the running processes and we really aren't given much access to the system in general. So how does one determine whether or not they've been hacked? So today in this video, we're going to cover a few of the methods that have been used historically in spyware investigations on iOS to identify signs of compromise and uncover the exploits being used. A spyware toolkit usually consists of multiple exploits engineered in such a way that seamlessly chains them together and allows for a very simple and effective delivery, such as by sending the victim an iMessage or having them click a crafted link. The most ideal way to uncover a spyware campaign would be to have access to these very messages or links. Given that these would be the actual entry point of the exploit chain capable of kickstarting the entire thing. If you have access to such a link, you can set up an environment to infect an iPhone in a controlled manner and intercept the relevant exploits to figure out exactly what's going on. For example, in one of the earliest cases of the Pegasus spyware used in 2016 against a UAE based journalist, suspicious text messages were received promising new secrets. And these messages also contained a crafted link. The victim in this case reported these messages to the researchers at Lookout and Citizen Lab and had the entire exploit chain uncovered, analyzed, and documented. It turned out that this suspicious link would have exploited a WebKit browser vulnerability on iOS and would have gone on to exploit two kernel vulnerabilities to install a malicious implant on the victim's phone.

[00:02:05]At the time, this was a very big deal as there hadn't been any previously known cases of a remote iPhone jailbreak being used in the wild like this. The details of the exploits were subsequently disclosed and the chain consisting of just three exploits became known as the Trident exploit chain. Similarly, other cases throughout the years have also been uncovered by sending suspicious samples to a group of security researchers. In 2021, another deployment of the Pegasus spyware, this time making use of a much more advanced exploit technology to keep up with the times was found to be used against a Saudi activist. This deployment's entry point was in the form of a crafted GIF file sent to the victim via iMessage. The researchers at Citizen Lab managed to retrieve iTunes backups from the victim's iPhone and extract samples of these gift files. We then saw an incredibly detailed breakdown of the exploit, which became known as the forced entry exploit from Ian Beer at Google Project Zero. Those are just two historic examples, but there of course have been many others with the most recent spyware campaigns being discovered just this year. A couple months ago on this channel, I deliberately infected one of my own iPhones with the Karuna spyware to see exactly how it works. And I've since gone on to do further analysis into parts of the exploit chain, analyzing one of the browser exploits that was being used. Check out those videos if you're interested in the technicalities.

[00:03:26]So, we know that given a suspicious message or web link, we could take the steps to analyze what might be going on, leading us to uncovering some spyware campaign. But what if your iPhone had already been infected and you'd somehow missed these earlier signs when the infection first occurred? How can we really determine if a phone has or hasn't been hacked? In terms of hard evidence that would actually confirm that a given iPhone had been infected, we really only have a couple things to look at. These include the crash logs left behind on the system, which can leave a trail of evidence indicating the types of exploits being used, and the diagnostics information produced by running the internal SIS diagnose feature on the iPhone. Let's first take a look at crash locks. In the iPhone settings app, under the privacy section, you'll find the analytics and diagnostics information, which will contain a bunch of text files storing information about system processes and apps that have crashed on the device.

[00:04:18]These are typically used by developers to understand bugs within their apps and they provide information about the state of memory and the function that was being executed at the time of the crash.

[00:04:28]The existence of crash logs in general is obviously totally normal. App Store apps and even Apple processes have bugs and can crash. But what can be telling, however, is the types of crash logs that you might find on a given iPhone.

[00:04:42]Exploit chains typically target memory corruption bugs and they use different techniques in order to try to control the layout of objects in memory and ultimately manipulate what a program does. There's very often a non-deterministic element to these techniques, meaning the exploit reliability might not be 100%.

[00:05:01]In cases where an exploit fails, it may have left the program's memory in such a messy state that it inevitably leads to a crash later on. These crashes get logged and can be considered a key part of evidence in identifying signs of infection. For example, take a look at the following two crash logs taken from an iPhone. Here we have a crash from a process which was terminated due to resource exhaustion. And here we have a crash from web content which is the Safari's browser renderer process which crashed because it was trying to access an invalid memory address. Out of these two examples, the web content one is more of a reason to be concerned.

[00:05:36]Resource exhaustion logs are trivial and occur all the time. If a process has a memory leak somewhere, for example, the colonel may recognize this and see that it is using too much memory and decide to terminate that process. This obviously has no relation to exploitation, so it isn't an indicator of compromise. It's just totally normal things to expect on a regular iPhone.

[00:05:56]The web content crash in this case, however, could be a cause for concern.

[00:06:00]We see that we crashed while trying to dreference some memory address that wasn't actually mapped. And it looks like we were deep within some call stack relating to the JavaScript core interpreter. These facts, while still not confirming signs of exploitation, might lead a researcher to more closely analyze this log to find out the root cause of the bug here. In this case, the crash is in fact caused by a failure in the initial stage 1 exploit from Karuna.

[00:06:24]An obvious caveat here is that legitimate crashes with no malicious intent behind them could just as easily be mistaken for a failed exploit type crash. It really requires the thorough root cause analysis to be performed before you can be sure. There's certainly an amount of intuition that researchers would possess, allowing them to more quickly filter out normal crashes and suspicious ones, but the only shorefire way to determine if it's suspicious or not is to conduct a full analysis inside something such as IDA Pro, where you can work out the exact root cause of the bug and evaluate whether or not that is the type of bug that an attacker would likely try to exploit. Other signs, such as the actual process that had crashed, may give you a strong indication one way or another.

[00:07:05]For example, typically you'll find a bunch of these stacks logs and crashes from normal iOS apps. These aren't interesting in the context of exploitation, but instead if you're seeing a bunch of kernel panic logs with the word panic in its name, then you'd be much more justified in thinking something could be going on. Similarly, if you're seeing consistent crashes from highly targeted system demons such as media playbackd, for example, you might have a good reason to investigate further. The root cause analysis technique closely ties in with the actual skill of vulnerability research and is used all the time by security professionals and exploit developers.

[00:07:39]So, let me know if you'd be interested in seeing a dedicated video on performing a full root cause analysis of a bug starting from just the crash log.

[00:07:46]The other form of hard evidence that you might find on an iPhone would be from the CIS diagnose archive that you can extract from the device. SIS diagnose is an internal diagnostics tool that you can activate by pressing a specific button combination on your iPhone. In the background, your iPhone will run some diagnostics tooling and a new CIS diagnose archive will appear in your diagnostics data directory and you can extract this onto your computer to see a bunch of interesting data about your phone and the state of the processes running on it. Here we actually do get to see a list of running processes, although of course it's not technically live, but just very recent. But if for example, you had some suspicious background implant running, it may be the case that it can be identified by looking at the list of processes here.

[00:08:26]There's all kinds of other system information provided in this archive.

[00:08:30]You get a variety of logs, you get kernel memory zone information, disk information, IO registry data, and a lot more. For the common user, making sense of this data is not so straightforward.

[00:08:41]So, companies such as I verify actually have tooling built into their mobile app that allows you to upload the CIS diagnose archive directly from your phone and in its back end, it will cross reference the data against all publicly known indicators of compromise. It will then report back to you in the app if any anomalies are identified. There's really no perfect way to identify spyware running on an iPhone. But for the common iPhone user running the latest iOS version, the risk of being hit with such advanced exploit technology is so incredibly low that it probably isn't worth worrying about anyway. In recent spyware cases, such as with the Karuna spyware, this was widespread, but it was actually very outdated and was not capable of exploiting any recent iPhone versions.

[00:09:22]Anyway, all of the vulnerabilities were already patched 2 years prior. So, despite these facts, if you're still overly cautious, just enable lockdown mode and let that do its thing. Hope you guys enjoyed this video. All links will be left down below in the description.

[00:09:35]Thanks for watching and I'll see you in the next