{
	"id": "cda43020-6815-4d3a-aefb-cf4924ba8e1a",
	"created_at": "2026-04-06T00:12:32.082302Z",
	"updated_at": "2026-04-10T13:12:57.857602Z",
	"deleted_at": null,
	"sha1_hash": "07b31eca860460d58ace3b27214bb7ff65bf2c25",
	"title": "Dusting off Old Fingerprints: NSO Group's Unknown MMS Hack",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1298198,
	"plain_text": "Dusting off Old Fingerprints: NSO Group's Unknown MMS Hack\r\nBy Cathal McDaid\r\nPublished: 2024-02-15 · Archived: 2026-04-05 13:26:19 UTC\r\nIn the ever-evolving landscape of mobile network security, it’s essential to stay vigilant and informed about the\r\nlatest threats. However to do so, sometimes we end up looking in places we would not normally look. Today, we\r\ndelve into a previously unknown mobile network attack known as the “MMS Fingerprint” attack, reportedly used\r\nby NSO Group, a well-known actor in the realm of surveillance technologies. How we found this attack – which\r\nhad essentially been hiding in plain sight – and how this attack might work, takes a bit of explaining. \r\nHiding in Plain Sight\r\nIn May 2019, WhatsApp, a widely used encrypted messaging platform, discovered a vulnerability in its system\r\nthat allowed attackers to install Pegasus spyware on users’ devices. The flaw was exploited through a WhatsApp\r\nvoice call, and it could compromise a device without the owner’s knowledge. WhatsApp blamed NSO Group for\r\nexploiting the vulnerability, which reportedly targeted a range of individuals, including journalists, human rights\r\nactivists, lawyers, and government officials. The attack was global in scope, with victims in various countries.\r\nSubsequently, in October 2019 WhatsApp sued NSO Group. Since then, appeals by NSO group to have the case\r\nstop have failed both in the US appeal court and the US Supreme Court.\r\nWhile interesting from a strategic and high-level viewpoint, at first glance there is nothing new here as this has\r\nbeen in the public domain for years. However, as part of its court case, WhatsApp/Facebook committed into\r\nevidence in October 2019 several exhibits. Most of this material was examined and discussed in the public\r\ndomain. However, what was not discussed were some specific details within a copy of a contract between a NSO\r\nGroup reseller and the telecom regulator of Ghana. Within that contract, in Exhibit A-1, was a list of “Features and\r\nCapabilities” offered by NSO Group. To telecom security specialists like us, these features were largely known,\r\nhowever there was a feature title that was (at first sight) unknown. This was the entry termed “MMS\r\nFingerprint”.\r\nhttps://www.enea.com/insights/dusting-off-old-fingerprints-nso-groups-unknown-mms-hack/\r\nPage 1 of 7\n\n“MMS Fingerprint” is not a term that was known about in the industry. At the time of writing a Google search\r\ndoesn’t find any other entries with this term, other than the court case itself. While we always must consider that\r\nNSO Group may simply be “inventing” or exaggerating the capabilities it claims to have (in our experience,\r\nsurveillance companies regularly over-promise their capabilities), the fact this was on a contract rather than an\r\nadvertisement suggests that it was more likely to be for real.\r\nHow Could an MMS Fingerprint Attack Work?\r\nGoing forward on that basis, I decided to consider how exactly an MMS Fingerprint could work. Next to no\r\ntechnical details were given, other than it stated it would:\r\nReveal the target device and OS version by sending an MMS to the device.\r\nNo user interaction, engagement or message opening is required to receive the device fingerprint.\r\nA starting point is the fact that Blackberry, Android, iOS devices were all listed as possible meant an OS-specific\r\nhack seemed unlikely. As a result we were probably looking at something vulnerable within the MMS flow itself.\r\nIn looking at the MMS flow, I concluded that perhaps – despite its name – the attack wasn’t happening over\r\nMMS, but rather via something else. To explain this, we have to look at the overall MMS flow itself, which is\r\nsomewhat ‘messy’, and that confusingly, sometimes the MMS flow is not using MMS.\r\nSometimes an MMS is not an MMS\r\nhttps://www.enea.com/insights/dusting-off-old-fingerprints-nso-groups-unknown-mms-hack/\r\nPage 2 of 7\n\nBelow is a diagram of a complete end to end MMS transfer. There are several main stages in an MMS flow.\r\n1. Initially the MMS message is submitted by the sender mobile device in a MM1_submit.REQ to the sender’s\r\nMMSC\r\n2. This then is forwarded by the sender’s MMSC to the recipient’s MMSC over the MM4 interface, using a\r\nMM4_forward.REQ. As a side note, this is different from how SMS works where the Sender’s SMSC is\r\nresponsible for both submission and delivery, so straight away things are more complex\r\n3. The recipient’s MMSC then notifies the recipient device that a MMS is waiting for it via a\r\nMM1_notification.REQ\r\n4. The recipient then retrieves the waiting MMS from its MMSC via a MM1_retrieve.REQ \u0026 MM1_retrieve.RES\r\n5. The later stages then involve a delivery report being sent to the sender MMSC/sender device once the MMS has\r\nbeen retrieved,\r\n6. Finally, an (optional) read report is sent to the sender MMSC/sender device once the MMS has been read.\r\nSo far, so (reasonably) clear. However things are less straight-forward when you being to investigate. One\r\ncomplexity in MMS is that when it was developed, the MMS standards designers needed a way for the recipient\r\ndevice to be notified there was an MMS waiting (for the recipient) in a time where there was no guarantee that\r\nevery device was MMS compatible. At the same time they did not want a system where the recipient mobile\r\nhttps://www.enea.com/insights/dusting-off-old-fingerprints-nso-groups-unknown-mms-hack/\r\nPage 3 of 7\n\ndevice was connected to the data channel when it did not need to be. As a result, MM1_notification.REQ used a\r\nsystem which would be supported by the vast majority of handsets, that is SMS. This also meant that the recipient\r\ndevice would only connect to the data channel once it was successfully paged over SMS. Technically speaking,\r\nMM1_notification.REQ is a special type of SMS, known as a binary SMS (WSP Push), that is used to notify to\r\nthe recipient MMS device’s user agent that an MMS message is waiting in the recipient MMSC for retrieval\r\n(using the field X-MMS-Content-Location).\r\nIn addition, the subsequent MM1_retrieve.REQ, isn’t really an MMS ‘message’ either. What this is, is a HTTP\r\nGET to the URL address contained in the X-MMS-Content-Location field in the previous\r\nMM1_notification.REQ. This GET should normally go to the recipient’s “mms” APN, to retrieve the MMS from\r\nthe MMSC. The interesting thing here, is that within this HTTP GET, user device information is included. It was\r\nsuspected that this may be the point that targeted device information could be leaked, and the MMS Fingerprint\r\ncould be “lifted”.\r\nLooking for Fingerprints and Why\r\nThis was certainly the assumption, however we needed to test the attack to be sure. To do this, we obtained some\r\nsample SIM cards from a random western European operator, and after some trial and error successfully sent\r\nMM1_notification.REQs (binary SMSs) to it. In these MM1_notification.REQs we set the content location to be a\r\nURL that pointed to a web server we controlled. Sure enough we were able to get the target device that received\r\nour MM1_notification.REQ to automatically do a GET to our URL, once it received the attack\r\nMM1_notification.REQ (binary SMS). This HTTP GET exposed the device’s UserAgent and x-wap-profile fields.\r\nA screenshot is below of a Wireshark decode of the MMS notification we sent, and the GET we subsequently\r\nreceived. This we believe is how an attacker would plan to execute an “MMS Fingerprint” attack, and we were\r\nable to show it was possible in real life.\r\nhttps://www.enea.com/insights/dusting-off-old-fingerprints-nso-groups-unknown-mms-hack/\r\nPage 4 of 7\n\nFigure 1: Initial Attack  MM1_ notifications.ind(MM1_notification.REQ) sent to target\r\nFigure 2: Subsequent MM1_retrieve.REQ(HTTP GET) received from targeted handset. Target device information\r\nin yellow\r\nThe next question to ask is why you would do this – what value is there in knowing the UserAgent and x-wap-profile. To answer that its worth explaining what they are:\r\nThe (MMS) UserAgent is a string that typically identifies the OS and device – in this case a Samsung\r\nphone running Android.\r\nx-wap-profile points to a UAProf (User Agent Profile) file that describes the capabilities of a mobile\r\nhandset.\r\nBoth of these can be very useful for malicious actors. Attackers could use this information to exploit specific\r\nvulnerabilities or tailor malicious payloads (such as the Pegasus exploit) to the recipient device type. Or it could\r\nhttps://www.enea.com/insights/dusting-off-old-fingerprints-nso-groups-unknown-mms-hack/\r\nPage 5 of 7\n\nbe used to help craft phishing campaigns against the human using the device more effectively. We have observed\r\nbefore that surveillance companies, when presented with the chance to get device information, invariably do. For\r\nexample, the Simjacker attackers requested to get IMEI (device identifier) as well as location information over\r\n93% of the time. In this case, UserAgent could potentially be more useful than IMEI as they reflect what’s\r\ninstalled on the device, rather than the static info contained in the IMEI field. One important note though is that\r\nthe MMS UserAgent, is different from the browser UserAgent which more people may be aware of (and which has\r\nits own privacy concerns and changes in). Both strings identify devices requesting online content but they\r\nrepresent different useragents running on the device.\r\nDetails on the Attack\r\nThe next question to answer is, having replicated the attack, do we think it is being used today? Thankfully, in our\r\ninvestigation over the last few months we did not observe any use of this vulnerability in the wild today. We are\r\nnot present in every operator in the world so it may be used, but we did not observe any of the known surveillance\r\ncompany sources we monitor using this technique. This may not be unexpected – as the contract document is from\r\n2015, and attackers may no longer use this method.\r\nSecond – NSO group state in their documentation that there is a caveat to the MMS Fingerprint they offer, which\r\nis “Note: MMS content appears on the target device”. This was the same for us in our initial tests of our\r\nMM1_notification.REQ attacks. In these, an MMS message notification is received by the target device which the\r\nphone owner can see. However, we were able to optimise the attack, and better conceal it, by changing the binary\r\nSMS to be a silent SMS. This was done by setting a TP-PID value of 0x40. As a result, no MMS content would\r\nappear on the targeted device, and the targeted person would not see anything on their phone. If the MMS\r\nfingerprint attack was done by using MM1_notification.REQ then it is hard to believe that an attacker wouldn’t\r\nhave known about this optimisation. One reason though for not using this is that encoding the message this way\r\n(as a silent SMS) would cause the message to stand out more on mobile operator networks, and so be more easily\r\nblocked by the recipient mobile operator.\r\nWiping Your Fingerprints\r\nThis takes us to the question on how to stop these attacks. In general, it is not that difficult to block the\r\nMM1_notification.REQ attack we tested, however there are some complications. Similarly, NSO themselves make\r\nit clear that when they list MMS Fingerprint that “This feature may be blocked by the local mobile network\r\noperator” .\r\nFirstly, on the device itself, subscribers are not helpless. One technique is that mobile subscribers could disable\r\nMMS auto-retrieval on their handset, to prevent the device automatically connecting as well. Typically this is\r\nconfigured on devices to download MMS automatically if the subscriber is home, and with a user prompt while\r\nabroad. But subscribers could set it to always require a user prompt. This same recommendation has been made\r\nfor other MMS exploits like Stagefright. This however should not be the recommended first line of defence, and\r\nsome devices do not allow you to modify this in any case.\r\nThe recommended first line of defence would be on the network side. The vast majority of mobile operators today\r\nfilter these Binary SMS/MM1_notification messages being sent, however what they are less strict on is them\r\nhttps://www.enea.com/insights/dusting-off-old-fingerprints-nso-groups-unknown-mms-hack/\r\nPage 6 of 7\n\nbeing received. This is because in the past some international/intercarrier MMS handling systems would route\r\nMMS messages from one operator to another not via MM4, but by sending the MM1 notification to the\r\nsubscribers of a different operator. In our analysis we still observed this being done today for ‘legitimate’ MMS in\r\nsome networks. This was probably much more common in the past when some operators had MMS, and others\r\ndid not. As a result, operators would need to investigate themselves before implement blocking of this. Inbound\r\nmessage Blocking would also need to handle outbound roamers, although this is standard functionality of any\r\nserious messaging security solution. For more assistance, the GSMA has produced a document called FS.42 which\r\ncontains recommendations on how mobile operator can protect themselves from Binary SMS attacks, of which\r\nthis attack would fall under.\r\nAnother line of defence on the network side is what could be done after a malicious binary SMS message is\r\nreceived. Blocking need not only mean stopping the MM1_notification.REQ being received but other techniques\r\ncould also be used to impede the attack. For example, mobile operators could look at restricting internet access via\r\nthe MMS ports from handsets, this would mean that even if the message was received, it would not connect to the\r\nattacker-controlled IP address.\r\nConclusion\r\nNSO Group have offered in the past a previously unknown and undiscussed telecom attack technique called MMS\r\nFingerprint. Based on the description and our knowledge and experience in this space we were able to recreate and\r\ntest an attack using the MMS flow which seems to match what was described in the legal exhibit. This attack is a\r\nstark reminder of how the mobile ecosystem can continually be threatened by a poorly understood but still heavily\r\nused technology that was developed without strong security in mind. While the MMS fingerprint attack that NSO\r\nGroup described is not extensive – only returning device info – it was useful enough to have been offered as a\r\nnamed attack technique to governments.\r\nThe history of Binary SMS attacks has given us a slow but very steady list of new reported vulnerabilities over the\r\nlast 20 years, of which this one is just the latest example. Companies like NSO group have an extensive track\r\nrecord of executing attacks against mobile phone users for many years, and Mobile Operators should evaluate\r\ntheir protection in place against this and other Binary SMS attacks.\r\nWith thanks to Fredrik Söderlund for his assistance.\r\nSource: https://www.enea.com/insights/dusting-off-old-fingerprints-nso-groups-unknown-mms-hack/\r\nhttps://www.enea.com/insights/dusting-off-old-fingerprints-nso-groups-unknown-mms-hack/\r\nPage 7 of 7",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.enea.com/insights/dusting-off-old-fingerprints-nso-groups-unknown-mms-hack/"
	],
	"report_names": [
		"dusting-off-old-fingerprints-nso-groups-unknown-mms-hack"
	],
	"threat_actors": [],
	"ts_created_at": 1775434352,
	"ts_updated_at": 1775826777,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/07b31eca860460d58ace3b27214bb7ff65bf2c25.pdf",
		"text": "https://archive.orkl.eu/07b31eca860460d58ace3b27214bb7ff65bf2c25.txt",
		"img": "https://archive.orkl.eu/07b31eca860460d58ace3b27214bb7ff65bf2c25.jpg"
	}
}