Colin Hardy lifts the lid on the inner workings of Pegasus in this incredibly detailed account


In 2016, Citizen Labs produced an excellent blog post which discussed several security updates released by Apple to patch vulnerabilities affecting Safari and Mac OS X. The vulnerabilities being patched were collectively known as “Trident” and were reportedly used by NSO Group (a clandestine organisation who we’ll get to in a minute) to hack into the mobile devices of civil society group members and human rights defenders on behalf of state-sponsored spyware campaigns. One such example described in the blog is the targeting of Ahmed Mansoor, an internationally recognized human rights defender, based in the United Arab Emirates (UAE).

Fast-forward to 2021, Forbidden Stories released details of an unprecedented leak of more than 50,000 phone numbers which apparently were targeted by customers of NSO Group using Pegasus malware. The consortium of journalists discovered that Pegasus has been widely misused since 2016 and at least 180 journalists have been targeted across India, Mexico, Hungary, Morocco and France, among others. Other potential targets include human rights defenders, academics, businesspeople, lawyers, doctors, union leaders, diplomats, politicians and several heads of states.

The consortium even met with victims whose phone numbers appeared in the leak. Forensic analysis of their phones was able to confirm the use of a zero-day, zero-click exploit affecting iMessage (known as “Megalodon”) to gain initial access to the victim’s device which was used as the vehicle to implant the Pegasus malware.

In this document I want to discuss some of the Pegasus malware analysis that I’ve undertaken from Android samples obtained in 2016 and also share some threat intelligence insights from a unique position I found myself in recently.

NSO Group

In August 2016 Mansoor received two text messages which contained some text, and a link for him to click. He didn’t click the link, but if he did his iPhone6 would have been completely compromised through a series of exploits known as ‘Trident’ which ultimately would lead to the Pegasus spyware being deployed to his phone.

Claudio Guarnieri, who runs Amnesty International’s Security Lab, said once a phone was infected with Pegasus, a client of NSO could in effect take control of a phone, enabling them to extract a person’s messages, calls, photos and emails, secretly activate cameras or microphones, and read the contents of encrypted messaging apps such as WhatsApp, Telegram and Signal.

By accessing GPS and hardware sensors in the phone, he added, NSO’s clients could also secure a log of a person’s past movements and track their location in real time with pinpoint accuracy, for example by establishing the direction and speed a car was travelling in.

NSO Group, who developed this malware, is an Israel-based company that sells Pegasus (amongst other things) which is described as a government-exclusive “lawful intercept” spyware product. They’re reportedly owned by an American venture capital firm, Francisco Partners Management and have a website where you can read about their work and their Board of Directors who have extensive skills in the technology landscape.

According to news reports and their LinkedIn page, NSO Group sells weaponized software that targets mobile phones to governments and has been operating since 2010 under the strapline of “Developing technologies to prevent and investigate terror and crime”. It should be noted they strenuously deny any claim that the list of 50k mobile phone numbers obtained by Forbidden Stories has anything to do with their platform.

The Pegasus spyware has existed for a significant amount of time, and is advertised and sold for use on high-value targets for multiple purposes, including high-level espionage on iOS, Android, and Blackberry devices.

Trident & Megalodon

There is an infamous saying in the world of malware analysis, that is “malware can hide, but it must run”. And indeed before malware can run, it must actually infect a victim device. Trident and Megalodon are examples of the sophisticated methods that NSO Group uses to infiltrate almost any handset on the planet.

Trident is a trio of vulnerabilities which when chained together allow for the complete compromise of an Apple device due to a flaw in Webkit, which is the web-browser engine used in Safari, Mail and many other Apple Apps.

CVE-2016-4657 is particularly fascinating as simply visiting a web page can lead to code execution on your device. There’s even a metasploit module now available that will generate this exploit for you, putting what was once a military-grade zero-day in the hands of everyday hackers. Keep your phones up to date kids.

Side note, this reminds me of an excellent talk by Amy Burnett who talks about attacking the browser for code-execution. In short, compromising tokens from the browser can often-times lead to the desired end-state of information theft without actually having to implant malware on the device.

Megalodon too is serious business. Amnesty International believes Pegasus was being delivered through this zero-click exploit up to the time of their report (July 2021) and remains functional through the latest available version of iOS. Let that sink in for a second. A zero-click exploit, affecting all known versions of iOS. Any iPhone can be remotely compromised if you know the mobile number. Chilling.

Megalodon appears to be a zero-day affecting iMessage, as Amnesty’s forensic analysis of infected devices has shown a lookup of a suspicious iMessage account (someone unknown to the victim) being performed which is immediately followed by a HTTP request which is carried out by a core telephony process running on the device.

Amnesty analysed traces of the HTTP request which were found in a cache file stored on the device and could see the phone sent metadata to an Amazon Cloudfront CDN controlled by the NSO Group. The HTTP response was approximately 250kb of encrypted data, which is considered to be the Pegasus malware.


Pegasus has extensive capabilities. It can be installed remotely on a smartphone without requiring any action from its owner and allows the malware operators to take complete control of the device, including accessing messages from encrypted messaging apps like WhatsApp and Signal, and enabling the microphone and camera and even tracking real-time location.

NSO Group even boasts of the benefits of Pegasus to prospective clients; revealing a shocking insight into the sheer power of this malware.

It even appears to have a sophisticated front-end for operators of Pegasus to view the details, often in real-time, from their victims.

Taken from this Lookout report, Pegasus is known to take advantage of both a remote jailbreak exploit and a technique called “hooking”. Hooking is where Pegasus will insert its dynamic libraries into the legitimate processes running on the device, helping the malware to remain undetected.

The list of victims recently disclosed apparently contained some heavy-hitting targets, including heads of state, and the overall impact of this malware is incredible.

Forbidden Stories, who are a Paris-based nonprofit media organisation, and Amnesty International initially had access to the leaked list and shared access with media partners as part of the Pegasus project, a reporting consortium.

The potential ramifications of being targeted by this malware are pretty scary. We know the phone can be completely compromised, but it’s how this data is then used which is mindblowing. Take this one example (of many similar scenarios reported):

There are some key hotspot areas that are called out in the various reports of countries who appear to be using (or rather mis-using) Pegasus. These hotspots will become more relevant a little later in this blog, but note the clusters in Mexico, North Africa, Middle East and Europe especially.

Malware Analysis

Note of Caution

TL;DR - Samples of Pegasus are difficult to come by (for obvious reasons). Secondly, please treat this overview as a reason why we as a malware analyst community shouldn’t blindly accept the attribution of malware samples made by others. Take data from other sources, but make your own judgements based on what you find in your research. The reason I point this out will become clear.

Finding Pegasus Samples

I’m yet to find a sample of Pegasus from an iOS device and the only samples or snippets that appear to be shared are those that target Android and are several years old. Anti-Virus vendors do appear to have signatures for this family of malware though, take for example this Android variant, it has detection from 18 vendors, most of which put it firmly in the Pegasus bucket. We’ll come back to this sample shortly.

VX-Underground who brand themselves as “The largest collection of malware source code, samples, and papers on the internet.” claim to have collected samples and are currently hosting them on their site for onward analysis:

Over 1.1k people liked this Tweet, and no doubt many blindly accept their attribution that all the samples being referenced here are in fact Pegasus. I’m less trustworthy than that, and prefer to make my own mind up. Whilst I don’t have a reference point (i.e. I don’t have a copy of Pegasus to know what it looks like) I do have some ‘expectations’ of how this malware should perform and what artifacts I’d expect to see.

How vx-underground made their attribution I’m unsure, but downloading the files yields the following file structure:


Name: com.lenovo.safecenter.apk

This file appears on Joe Sandbox with the name of “com.lenovo.safecenter.apk” and tagged as ‘Pegasus’. Whilst this apk does look like malware, to me this looks like Lenovo’s own system tracking code (which I guess is basically spyware).

You can use the Android SDK’s apkanalyser tool to parse details of the apk permissions:

the files list verb is handy to see what is contained in the apk:

And the manifest print verb is also useful

Anyway, for more, check out the -h flag

I side-loaded the apk onto an Android Virtual Device which resulted in an app install which looked like this

Summary - there’s nothing in here which smells like NSO Pegasus malware. Yes the apk looks like spyware, but this is likely the kind of bloatware / tracking shit that you get when you buy a Lenovo phone.


Name: 530b4f4d139f3ef987d661b2a9f74f5f.axml

From VirusTotal this does show signs of being linked to Pegasus given what many reputable AV companies tag the malware family as. But we’ll remain open-minded.

I’ve no idea how to parse this file format correctly, running ‘file’ on the file shows it to be an Android XML binary, but for someone who doesn’t develop Android applications I’ve no idea what this is.

However, all is not lost, running strings on the file makes it look like a manifest file, with the various permissions its associated apk should be capable of taking advantage of. If you can think of a permission, it uses that permission.

Summary - I don’t know which other file out of the Zip content this manifest relates to. ¯\_(ツ)_/¯


Name: Binary_SMS_Receiver_base.apk

This appears to be another apk file, Googling the hash shows lots of attribution to Pegasus and from VT we can see a submitted name of the package was “Binary_SMS_Receiver_base.apk” - giving a good indication of what this is designed to do.

I ran this apk through apktool using the d parameter and dumped all the .smali files to peruse through the strings.

TL;DR - I didn’t see anything worth spending more time on here and side-loading the app onto an Android Virtual Device yields an app interface, which to me doesn’t lend itself to a stealthy nation-state-level backdoor.

Yes, Pegasus will no doubt make use of Binary SMS’s, but to me this appears to be an app for someone to test this functionality.



This is another apk file, with less attribution to Pegasus from the AV vendors on VirusTotal but with still some community comments suggesting the link. It could be this apk is more generic and not specific to just Pegasus, and you can get a feel from the manifest file the permissions required and the general flow of activity.

Again, using apktool d on the apk, it’s easy to extract the contents. The most interesting thing that caught my eye was an ELF binary named “inject” and therefore the most telling clue about what this malware is designed to do.

In order to inspect the ELF, first if you run ‘file’ on it you’ll note that the symbols are not stripped.

To analyse this we need to pivot to Ghidra which handles this file-format with ease. What I like about Ghidra is how you can easily hop around the file and it shows you the more readable decompiled version of the code in the right-hand window.

For example, looking through the function calls you can see functions named inject_process which is pretty telling and find_pid_of and lots of references to ptrace which is used as part of attaching to another process.

Outside of the general features here of injecting shellcode into other processes, I don’t think there’s anything else too interesting to report. I did sideload the app onto my Android Virtual Device and was presented with this GUI:

Not what I’d expect from a stealthy-Pegasus malware install, I didn’t take the time to analyse this app any further. I did note though this app does make various network requests to the following domain:

After extensive threat-intelligence research (aka Googling once) I don’t see any attribution of this domain to anything NSO-related. Moving on.


Another heavy-hitter on VT with lots of ‘Pegasus’ attribution

Joe Sandbox has a lot of data to go through from the execution of this APK. But let’s poke around it ourselves.

There are many ways of analysing apks, a popular tool to decode them is apktool which can be easily installed on a mac using homebrew. Decoding the file will yield something akin to this.

We can use AndroidStudio to parse the whole decoded apk and browse through the files. I’m not an Android developer and would put myself in the beginner class for malware analysis of Android code, but browsing through I like to pull out strings of interest and pull at threads.

For example, where I see constant strings like this one’s interesting to Google and see if they relate to any other sample. In this case I only see a hit in Hybrid Analysis to this very sample. There are lots of other similar hardcoded strings, and also many base64 encoded strings which don’t directly decode to obvious plaintext. The code appears obfuscated, difficult to analyse and full of misdirection - exactly what we like as Malware Analysts, right?

A nice little regex I use in CyberChef is to extract all the strings between quotes, as often they’d contain hardcoded values and strings of interest:

Ok, let’s dig a bit deeper then. Using the AndroidStudio to parse the analysed APK means we’re looking at .smali files, which are less readable than if we converted the classes.dex file to an actual JAR. Luckily there’s a handy tool for that, so go back to the original APK file, unzip it and extract the classes.dex file. Then you can run to convert the dex file into a Java JAR which can then be viewed in JD-GUI to parse the class file in a more readable code-format.

I got a couple of errors running this, but even so the file rendered fine in JD-GUI

So, it looks like those hardcoded strings are a mix of base64 encoded values with some strings which appear similar to hashes (spoiler - they’re not). Looking at this function as an example:

public static String ApfJJJJJuJJJJJVQDtgVpIxG4409()


Object localObject = "VwFELlxaEQRK".getBytes();

localObject = Base64.decode((byte[])localObject, 0);

localObject = new String((byte[])localObject);

StringBuilder localStringBuilder = new StringBuilder();

for (int i = 0;; i++)


int j = ((String)localObject).length();

if (i >= j) {



j = ((String)localObject).charAt(i);

int k = "0d0b35aa8ba8400aa272936511ad6c77".length();

k = "0d0b35aa8ba8400aa272936511ad6c77".charAt(i % k);

char c = (char)(j ^ k);



localObject = localStringBuilder.toString();

return (String)localObject;


It looks like localObject is base64 decoded, and then each byte is XOR’d with each byte in the variable k and then returned. In this case the decoded value equates to the plaintext string:


So at this point, there’s a lot of these .class files in JD-GUI which have these decoding functions which all take unique Keys and also different Base64 encoded values which are XOR’d together. I used JD-GUI to dump out all the files (they’ll be saved as .java extensions) and then I just cat’d all of them out and used the regex from earlier to extract all data between quotes.

Then I wrote some quick Python to produce a simple reader to XOR the strings together having first taken care of the base64 encoded content

And look Mom….strings, lots of strings!

These decoded strings really help understand the true capabilities of this malware and the applications it targets. Example, some interesting strings from the file

b'getMessage,a,append,a,exists,a,append,getLooper,toString,equals,append,equals,a,append,append,append,a,append,append,append,getContentResolver,toString,equals,G,B,a,a,a,append,a,currentTimeMillis,toString,a,append,append,a,a,a,append,equals,toString,toGMTString,post,append,equals,a,a,a,toGMTString,append,toString,a,toString,c,getMessage,getContentResolver,equals,toString,equals,toLocaleString,append,setComponentEnabledSetting,equals,getMessage,toString,a,toString,append,getContentResolver,equals,getContentResolver,a,append,append,a,getContentResolver,toString,a,A,getAction,getIntExtra,toString,append,append,equals,append,start,append,getPackageManager,append,C,getContentResolver,D,equals,getStringExtra,C,a,CoreReceiver onReceive action:, post,onReceive Exception- ,c,a,addServerPushListener start: ,addServerPushListener token id i@,tcp://,:,addServerPushListener invalid paA,MOSQ_ERR_INVAL,MOSQ_ERR_CONN_REFUSED,addServerPushListener exception-O,addServerPushListener creating n^, password: , url: ,MOSQ_SERVICE_ON,wake up,CoreReceiver WAKE_UP: ,dontKill - ,CoreReceiver - ,whatsUp,CoreReceiver WHATS_APP,twitter,CoreReceiver TWITTER,facebook,CoreReceiver FACEBOOK,kakao,CoreReceiver KAKAO,viber,CoreReceiver VIBER,skype,CoreReceiver SKYPE,GMail,CoreReceiver General Mail,mail,CoreReceiver Email type,Contact Scan,CoreReceiver CONTACT_SCAN luchSc\x07,finishLocationMonitor,RemoveHistory,timeToStop,toRemove,keyboard,restart,CoreReceiver USSD RESTART check T,CoreReceiver USSD RESTART check g,CoreReceiver USSD RESTART check \x0b,CoreReceiver USSD RESTART call f\x01,/system/csk,changeSettings remove auto updat^,reboot,CoreReceiver USSD will NOT be RE=,c,a,equals,toString,H,CoreReceiver,DOWNLOAD_UPGRADE,DOWNLOAD_UPGRADE_STOP,equals,a,append,getMessage,equals,equals,c,append,toString,append,append,a,append,toString,toGMTString,equals'

References to “USSD” had me googling and TIL this is a message format that creates a real-time connection during a USSD session. The connection remains open, allowing a two-way exchange of a sequence of data. This makes USSD more responsive than services that use SMS.

This certainly feels more like the Pegasus I was expecting. There’s lots of references to the applications that Pegasus is known to intercept (e.g. Facebook, Viber, WhatsApp etc) and also the application permissions allow it to access pretty much every aspect of the device, for example calls, messages, calendar, photos, location etc. See here for a full breakdown.

Also note there are several binaries stored as resources in this apk, all are available on VirusTotal and don’t appear specific to Pegasus. One binary, addk, is not-stripped therefore it makes decompiling in Ghidra quite straight forward giving a clear indication what the code is doing, in this case process injection.

I side-loaded the APK on to an Android Virtual Device and didn’t see any visual evidence of the app being loaded (as I’d expect from malware such as this) but running:

adb shell dumpsys

confirmed the presence of the malware running and listening on the device.

Note, if you have an Android or iOS device that you’d like to check for the presence of Pegasus, then I recommend mvt which is a tool developed by Amnesty International for this specific purpose and can help you identify any potential Pegasus infection.

Side note, I did actually attempt to run mvt against a backup of my Android Virtual Device, but kept hitting the same wall where the code failed to find the SMS backup folder (because it didn’t exist), even despite me re-creating the folder and necessary files within the backup therefore the code failed to further execute.

Looking at the code to analyse an Android backup, it appears the tool works only by parsing the SMS messages within the backup, then parsing each body of the messages and looking for URLS. Then checking the domain within those URLs against a known list from Amnesty’s IOC database. More checks are made if the adb option is used to interface with the device directly, as follows:

but I wasn’t able to do this against my virtual device. Sad face.


In short, don’t blindly trust the attribution of others if you’re studying a particular malware sample. Make your own assessment based on your own analysis if the code is in fact what you think it is, and document those reasons and share your findings with the community. I and others will benefit from your research. As we saw in this case, my opinion, is that from 5 files being advertised as Pegasus I only see one file as having any credible Pegasus-like features.

Threat Intelligence

Going back to the original story, it’s clear that Mansoor has been a target for some years by nation-state operatives who seem to really want to compromise his devices.

What I found interesting was the two text messages he received back in 2016. They contained two URLs:



which can be broken down into the following regular expression:


Whenever I see any malicious URL like this, I immediately check to see if the domain is available for registration. Who knows, one day I may save the world.

Side note, I created a hacky tool to check domains en-masse in case you ever need to here.

In this case, guess what….

So of course, I couldn’t help myself. I quickly registered the domain and set up a simple nginx box to monitor incoming web requests and of course I’ve been hosting benign content.

And you know what? There’s still hits to those URLs. LOTS of them!


What does this mean? Well, this could be researchers still performing analysis of the links. Meh, maybe. But, I saw a lot of traffic to these specific endpoints, like 1000+ hits in the space of a week. And what’s more, looking at the User-Agents and Referers it's clear these are people clicking links sent through popular messaging apps like Telegram from their phones.

So, are these links still being distributed maliciously??? Am I now part of NSO Group’s infrastructure? Are the IP addresses I’m capturing the targets of this military-grade malware?

Access Logs Analysis

Between 23/07/21 and 31/07/21 I observed 1270 hits to the subdomain with a path matching the URL structure in the CitizenLab IOC list


This equated to 457 unique IP addresses

Using MaxMind I performed a bulk lookup of the IP data to get geo-ip details.

When the IPs are mapped to their approximate locations, there’s some interesting synergy between the hotspots shown earlier of victims being targeted and these hits to the SMS URLs which are still being made.


  • Cluster around Middle East (Egypt, Israel, Syria, Jordan, Lebanon, Iraq)
  • Cluster around North Africa (Morocco, Algeria, Tunisia)
  • Lots of hits across EU, including Russia
  • Many of the US hits are Google, Facebook and other big-tech
  • Hits in Antigua were from Telegram
  • 11 hits not located

Aside from Facebook (more on that in a minute) the next most popular ISP was Telecom Egypt and Yemen Net.


Number of Hits



Telecom Egypt


Yemen Net


Google Proxy


EarthLink Iraq


Syrian Telecom


Datacamp Limited


Digital Ocean


Zain Jordan


Cogent Communications


MaxMind Location Accuracy

As an aside I wanted to see how useful the location details were from the maxmind data. They provide a field to indicate the accuracy of their geo-coordinates, the best accuracy they have appears to be 1km (pretty decent!) and the worst being 1000km, which let’s face it is a pretty wide region.

For results which returned a high probability of being a residential carrier, the location accuracy appeared surprisingly high. Take for example this hit from an Israeli IP address which was given a location accuracy of 1km.

It’s not hard to guess in which local village this particular visitor to my site was from. Notably, there are some interesting businesses at this location, and perhaps connected to a victim of this campaign.

In densely populated areas, even with an accuracy of 1km it’s not really beneficial in identifying the user of the IP, take for example this hit observed from Yemen with a 1km accuracy radius.

I did test this using my home personal IP address, which reported an accuracy of 5km and my home address was within this boundary. So, I’m pretty confident in the data, and don’t disagree with their accuracy radius ratings.

Time Distribution

Not sure this is particularly relevant, but there is a definite spike in activity in the evening when most of these hits were observed.

Referring Sites

This mainly showcases that Telegram is the most popular referring messaging service to the hits I observed.

Also note the entry for ir.ilmili.telegraph which is a messaging service built on Telegram’s API which equates to two unique users, one from Yemen and the other in Iraq.

Virus Total

It’s good when services such as VirusTotal make their traffic easily distinguishable, in this case via their user-agent. There’s nothing to note from their IP addresses here, hence why I’ve shown them unredacted.

What’s interesting though is that these URLs are being scanned by VT to assess the content for signs of malicious behaviour. For example, this URL was only first scanned by VT on 27/07/21 - someone is trying to perform analysis of this site. I’m surprised it hadn’t previously been scanned given the original threat campaign was in 2016.

Of course, I’m not serving any malicious content at all, yet 5 engines find the site malicious.

I assume this is based on known attribution to the NSO Group.

WhatsApp Hits

When you share a link in WhatsApp (and many other platforms), the app itself will attempt to fetch data about the link, for example the html title and perhaps a preview of the site itself. The trick is though, that WhatsApp will perform this web request from your IP address. Yes, your message may well be end-end encrypted, but if you share a link then the website operator will see your IP in their access logs.

In this case, I saw 8 hits from WhatsApp linked user-agents. Side note, if you know what the “i” and the “A” mean in these user-agent strings, please let me know (perhaps Desktop versus Mobile?). Edit - the obvious was pointed out to me...yolo.

What’s interesting here is there are 3 more request paths than previously reported, highlighted below:









These fit the regex for the structure of the links being distributed by Pegasus operators. Given the original target of Mansoor was in 2016, I find it very curious that these links are still in operation and being distributed in the wild via WhatsApp with these new links being found that were previously unknown. Are these URLs from an unknown campaign, i.e. another target of this incredible malware?

The hits for these links were made from the following subset of countries, known to be highly targeted by Pegasus malware from nation-state operatives.

  • Iraq
  • Israel
  • Morocco
  • Egypt

It raises the question, is there still an active campaign which uses this URL structure? Other than these hits being from investigators or journalists, I don’t see any other explanation. Surely people aren’t still chatting / forwarding these URLs 5 years after the original campaign. ¯\_(ツ)_/¯

Telegram Users

Parsing the logs there are 85 hits where the Android Telegram messenger app is in the Referrer field and the source IP is the user who clicked the link from a Telegram message (redacted below).

Most of these users are in the Middle East, again from countries known to be heavily targeted in the recent list of 50k victims.

There are 52 separate user-agents that have hit the links using Telegram.

These represent a wide array of mobile devices, and also Chrome versions, many of which are significantly out-of-date:















Also, oddly, all the hits from Telegram were from Android devices. I didn’t observe a single user-agent which would indicate an iOS device. The range of Android devices were:








Infinix X626B

Infinix X650C

Infinix X660B

Infinix X680

Infinix X693


Lenovo L19111







Redmi Note 8

Redmi Note 9S
























vivo 1906

vivo 1938

Opsec Aware User

There were hits observed from Telegram in the US which originated from DigitalOcean IP addresses. The referer field in these requests is the telegram messenger. This is where the user piped their mobile traffic through a DigitalOcean SOCKS proxy.

This user-agent indicates an outdated Chrome version (version 90) as the latest is 92.x and also the user is running Android 10 (from September 2019).

Looking at a Shodan view for this victim IP, it looks like they are indeed running a SOCKS proxy which the Telegram traffic passed through.

Despite the traffic passing through DigitalOcean, the user-agent still shows the device:

"Mozilla/5.0 (Linux; Android 10; Infinix X660B) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.91 Mobile Safari/537.36"

This isn’t a handset I’m familiar with but a quick Google immediately brings back links to buy this handset in Africa (Nigeria and Kenya). Perhaps these handsets are more popular there? It’s very weak, but possibly where this user is located. Note, I can buy this handset on Amazon, so this is a terrible assumption. Yolo.

Facebook Hits

I noticed there were a total of 371 hits with the user-agent string

"facebookexternalhit/1.1 (+"

Visiting that php page yields an obvious explanation that these hits are as a result of people sharing the link to the site with other users.

The IP addresses of these hits belong to Facebook and therefore I have no issue in sharing them unredacted.

What’s interesting however is searching through the logs for hits where the Referer field is from Facebook, but the User-Agent does not match the above. This yields the IP addresses of actual users who have subsequently clicked the link from a message shared with them on the platform.

These equate to 5 unique IP addresses which originate from two countries only; Jordan and Syria, and yet again are all from Android devices with various outdated Chrome versions.

  • Mozilla/5.0 (Linux; Android 10; STK-L21 Build/HUAWEISTK-L21; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/90.0.4430.82 Mobile Safari/537.36 [FB_IAB/FB4A;FBAV/328.;]
  • Mozilla/5.0 (Linux; Android 8.0.0; LDN-L21 Build/HUAWEILDN-L21; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/91.0.4472.101 Mobile Safari/537.36 [FB_IAB/FB4A;FBAV/322.;]
  • Mozilla/5.0 (Linux; Android 10; TECNO LD7 Build/QP1A.190711.020; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/91.0.4472.164 Mobile Safari/537.36 [FB_IAB/FB4A;FBAV/328.;]
  • Mozilla/5.0 (Linux; Android 9; SM-J730F Build/PPR1.180610.011; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/90.0.4430.210 Mobile Safari/537.36[FBAN/EMA;FBLC/ar_AR;FBAV/;]
  • Mozilla/5.0 (Linux; Android 10; SM-A600F Build/QP1A.190711.020; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/91.0.4472.120 Mobile Safari/537.36 [FB_IAB/FB4A;FBAV/327.;]


Pegasus malware is the most incredible spyware I’ve ever studied without having my hands on a true sample to play around with. Not only is the malware capable of compromising all data, in real-time, from almost any mobile device the methods used by NSO Group to propagate the malware means there is literally no way to defend against this level of sophisticated attack.

Forbidden Stories has coordinated and produced some amazing journalism to highlight just how widespread this eavesdropping activity really is, and ultimately how this malware is being misused as part of mass surveillance by governments across the globe. And somewhat surprisingly, I’ve been able to capture probable victims of these campaigns who are attempting to access URLs previously used by NSO Operators to compromise phones en masse.

My view though, is that nothing will change. NSO Group will continue to operate, continue to innovate and continue to develop new and ever-more sophisticated ways to achieve their end target. We in the cyber security research and defence community can really only hope to help minimise the impact when these infections do occur and hopefully give adversaries operating this malware a more difficult ride through sharing intelligence, bolstering defences and working with victims to best protect their information.

Thank you for reading these notes. They are a collection of my thoughts, analysis and musings that hopefully inspire you to learn more in this field and help defend individuals and organisations from malware attacks.




Share this post