{ "id": "796d3f7e-8261-41dd-af31-1f1d684722cf", "created_at": "2026-04-06T00:08:28.379747Z", "updated_at": "2026-04-10T13:11:21.891962Z", "deleted_at": null, "sha1_hash": "e8aa983cd7a4e4d0e9bd8e5df148a9a893576633", "title": "iOS URL Scheme Susceptible to Hijacking - TrendLabs Security Intelligence Blog", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 1620276, "plain_text": "iOS URL Scheme Susceptible to Hijacking - TrendLabs Security\r\nIntelligence Blog\r\nBy Trend Micro\r\nPublished: 2019-07-12 · Archived: 2026-04-05 14:36:15 UTC\r\nby  Lilang Wu, Yuchen Zhou, Moony Li\r\nApple manages application security and privacy concerns by using a sandbox mechanism for iOS that constrains the\r\nreachable resources for each application. This was created to contain damage if an app was compromised, and all apps\r\ndistributed through the App Store adopt it. However, because of this access control, communication between apps becomes\r\nmore difficult.\r\nFortunately, Apple provides several carefully designed methods to assist app communication, the most common of which\r\nis the URL Scheme. In essence, this is a feature that allows developers to launch apps on an iOS device through URLs. It\r\nis a method of conveying information from one app to another. For example, when a URL with facetime:// is opened,\r\nFaceTime places a call — this is the URL Scheme coming into play. It is a very convenient shortcut; but the URL Scheme\r\nis designed for communication, not security.\r\nBelow, we discuss how abuse of the URL Scheme can potentially result in the loss of privacy, bill fraud, exposure to pop-up ads, and more. We illustrate the misuse using several official iOS apps from the Chinese market, notably the messaging\r\nand mobile payment app WeChat and the retail app Suning. There are many other apps with the same features and\r\ncapabilities as WeChat and Suning that are also vulnerable to the attacks outlined below. We notified and coordinated with\r\nvendors, particularly WeChat, and reported these attacks to the Zero Day Initiative.\r\nHow does it work?\r\niOS allows one single URL Scheme to be claimed by multiple apps. For instance, Sample:// can be used by two completely\r\nseparate apps in their implementation of URL Schemes. This is how some malicious apps can take advantage of the URL\r\nScheme and compromise users.\r\nApple addressed the issue in later iOS versions (iOS 11), where the first-come-first-served principle applies, and only the\r\nprior installed app using the URL Scheme will be launched. However, the vulnerability can still be exploited in different\r\nways.\r\nhttps://web.archive.org/web/20211023221110/https://blog.trendmicro.com/trendlabs-security-intelligence/ios-url-scheme-susceptible-to-hijacking/\r\nPage 1 of 7\n\nURL Schemes affect account privacy\r\nThe URL Schemes function as portals for apps to receive information from other apps. As mentioned above, since Apple\r\nallows different apps to declare the same URL Scheme, malicious apps can hijack sensitive data of certain apps. This\r\nvulnerability is particularly critical if the login process of app A is associated with app B.\r\nFor instance, the Suning app (a retail application) allows a victim to log in using their WeChat account. The normal\r\nauthentication process (seen below) is that the Suning app generates a URL Scheme query and sends it to WeChat App.\r\nWhen the WeChat app receives the query from the Suning app, it requests a Login-Token from the WeChat server and\r\nsends it back to the Suning app for authentication.\r\nFigure 1. Suning app login with WeChat account associated with WeChat app\r\nOur research found that Suning always uses the same Login-Request URL Scheme query to request the Login-Token, but\r\nWeChat does not authenticate the source of the login request. This allows an attacker to use an app’s Login-Request URL\r\nScheme for malicious purposes.\r\nAttackers can use Suning’s Login-Request URL Scheme query to request the Login-Token of a victim’s WeChat account.\r\nHe can then use that token to log into the Suning app with the victim’s WeChat account (illustrated below). This process\r\nallows an attacker to collect personal information or abuse access to both accounts.\r\nhttps://web.archive.org/web/20211023221110/https://blog.trendmicro.com/trendlabs-security-intelligence/ios-url-scheme-susceptible-to-hijacking/\r\nPage 2 of 7\n\nFigure 2. Malicious actor logging into the Suning app with victim’s WeChat account\r\nFor the abovementioned attack to work, an attacker must first get Suning’s Login-Request URL Scheme. Capturing it from\r\nthe Suning app requires creating a whole separate app with WeChat’s URL Scheme (WeChat’s URL Scheme could be\r\nfound in the field of LSApplicationQueriesSchemes in Info.plist of Suning). With the legitimate WeChat URL Scheme, a\r\nfake-WeChat can be crafted and Suning will query the fake one for Login-Token.\r\nIf the Suning app sends the query, then the fake app can capture its Login-Request URL Scheme . Our analysis found that\r\nthis Login-Request includes the constant parameter with the constant value in multiple querying rounds, which gives\r\nattackers the chance to replay the request.\r\nFigure 3. Captured Login-Request from Suning to WeChat\r\nFigure 4. Captured Login-Token from WeChat to Suning\r\nAs illustrated in figures 3 and 4, Suning crafts its query by inserting a unique and complex URL Scheme\r\n(wxe386966df7b712ca) for WeChat to respond to. That particular URL is registered on WeChat as a Suning login. WeChat\r\nrecognizes it but it will not authenticate the source of the Login-Request. Instead, it will directly respond with a Login-Token to the source of the request.\r\nUnfortunately, the source could be a malicious app that is abusing the Suning URL scheme.\r\nhttps://web.archive.org/web/20211023221110/https://blog.trendmicro.com/trendlabs-security-intelligence/ios-url-scheme-susceptible-to-hijacking/\r\nPage 3 of 7\n\nFigure 5. Stolen Login-Token by the Malicious app named URLSchemeAttack\r\nThis Login-Token can allow the malicious actor to access the victim’s Suning account, exposing personal information. The\r\ncompromised account can also be used for malicious purposes.\r\nFigure 6. Attacker’s device logs into victim’s Suning account using stolen Login-Token\r\nThis issue is not exclusive to these two apps, the vulnerability exists in many apps that have this particular login feature.\r\nURL Schemes abused for bill phishing\r\nCounterfeit URL Schemes can be used in multiple attack scenarios. One other example is bill replay phishing, which tricks\r\nvictims into paying others’ bills. This attack uses both social engineering and the vulnerability of URL Schemes.\r\nhttps://web.archive.org/web/20211023221110/https://blog.trendmicro.com/trendlabs-security-intelligence/ios-url-scheme-susceptible-to-hijacking/\r\nPage 4 of 7\n\nIn general, bill replay phishing is done by sending the URL Scheme of a billing request to certain apps with a payment\r\nfeature. This attack can be illustrated by a specific feature of DiDi or MeiTuanDaChe (both transportation apps) associated\r\nwith any app with a payment function.\r\nTo reproduce this attack, we can look at issues with WeChat’s capabilities as a payment-app. This has not been seen in the\r\nwild, but is possible with the given parameters. Attackers can use the strategy mentioned above: create a fake WeChat with\r\nthe same URL Scheme of the legitimate one, and it will allow attackers to capture the URL Scheme billing request from\r\nDiDi or MeiTuanDaChe.\r\nWith the billing URL Scheme, an attacker can replay a billing request to any legitimate WeChat app and it will\r\nautomatically call up its payment interface. Because the attacker is using the stolen (but legitimate) URL scheme request\r\nof DiDi or MeiTuanDaChe, the victim’s legitimate WeChat app will accept the payment request.\r\nFigure 7. Proof that the URL Scheme request can be replayed\r\nAdmittedly, normal users might not be deceived, since they are unlikely to pay for a random billing request popping up in\r\ntheir WeChat payment interface. Nevertheless, this feature tremendously increases the probability of fraud. A user can\r\nabsentmindedly click the pay button, or may think that this is a legitimate payment request.\r\nAnother attack scenario is possible as well, specifically using SMS social engineering and the URL scheme. Using the\r\nsame apps as an example, the attack starts by taking advantage of the billing process.\r\nThose who use DiDi or MeiTuanDaChe apps regularly get SMS messages to remind them of their unpaid bills. An attacker\r\ncould generate the same SMS message to victims with a link containing the URL Scheme of a billing request — this\r\nbilling request can be any request from the attacker. This link will be redirected to WeChat payment interface, and will ask\r\nvictims for payment. This is an easy way to manipulate victims and trick them into paying bills that do not belong to them.\r\nhttps://web.archive.org/web/20211023221110/https://blog.trendmicro.com/trendlabs-security-intelligence/ios-url-scheme-susceptible-to-hijacking/\r\nPage 5 of 7\n\nFigure 8. Bill Replay Phishing from SMS message\r\nFortunately, the latest version of WeChat has a new security strategy to prevent this billing replay attack: WeChat will not\r\naccept a billing request if it was conveyed by MobileSafari. However, billing replay is still feasible if the billing request is\r\ninitiated by apps such as Chrome, Message, Gmail, and others.\r\nURL Scheme used in pop-up ads\r\nOne more issue with the URL Scheme is that it can be used to launch applications. This means that once a certain URL\r\nScheme is registered by a malicious app, there is a chance that the malicious app will be launched when the URL Scheme\r\nis called. In our research, plenty of apps that our system audited were found taking advantage of this feature to show ads to\r\nvictims.\r\nPotentially malicious apps would intentionally claim the URL Scheme associated with popular apps:  wechat://, line://,\r\nfb://, fb-messenger://, etc. We identified some of these malicious apps:\r\nSHA256 Bundle ID\r\nNumber\r\nof\r\ndeclared\r\nURL\r\nSchemes\r\nper app\r\n1377742266f2a56f0424c1884c9c1fab8daa113b51c7f4d2ac4b2f88b770a1f5 co.Mu.Mu 490\r\nc329fc984a2d75e4f1f15288cb5d9383c2f439dbae67bf808759bc5bc8336aee co.medaistream.pokemap2 430\r\n93326edbbd8863fbb0d2e602e1d8a7348349053ae144912286e78fb17a685c0f co.musical.Musical 491\r\nfe8fe4226ba17924cd31505a07b19691b5eecf2e9ae677bc9765130020662b89 com.musictechnology.Musia 491\r\nMitigation and solutions\r\nhttps://web.archive.org/web/20211023221110/https://blog.trendmicro.com/trendlabs-security-intelligence/ios-url-scheme-susceptible-to-hijacking/\r\nPage 6 of 7\n\nThe URL Scheme can be dangerous and is not recommended for the transfer of sensitive data. Attackers can take\r\nadvantage of the non-authentication feature since communication and data is transferred regardless of the source or\r\ndestination.\r\nAffected vendors were notified July and August of 2018 when the vulnerability was first found, and we noted many of the\r\nvulnerable apps were actually popular downloads from the Chinese App Store. Apple is aware of this threat; they have\r\nalready notified developers about the dangers of URL Schemes and offered recommendations. They specifically state:\r\n“URL schemes offer a potential attack vector into your app, so make sure to validate all URL parameters and discard any\r\nmalformed URLs. In addition, limit the available actions to those that do not risk the user’s data.”\r\nFor developers, universal links are generally recommended as a best practice for deep linking. Setting up a universal link\r\n(HTTP or HTTPS) login interface, and musing a random identifier to authenticate the received login token locally,\r\nprevents hijacking and malicious login token replaying.\r\nFurthermore, Trend Micro detects the potentially malicious apps that may take advantage of this feature. Our vulnerability\r\nscan system will be able to recognize the malicious apps that potentially misuse the URL Scheme. Trend Micro™ XGen™\r\nsecurity provides high-fidelity machine learning that can secure the gateway and endpoints, and protect physical, virtual,\r\nand cloud workloads. With technologies that employ web/URL filtering, behavioral analysis, and custom sandboxing,\r\nXGen security offers protection against evolving threats that bypass traditional controls and exploit known and unknown\r\nvulnerabilities. XGen security also powers Trend Micro’s suite of security solutions: Hybrid Cloud Security, User\r\nProtection, and Network Defense.\r\nSource: https://web.archive.org/web/20211023221110/https://blog.trendmicro.com/trendlabs-security-intelligence/ios-url-scheme-susceptible-to-hijackin\r\ng/\r\nhttps://web.archive.org/web/20211023221110/https://blog.trendmicro.com/trendlabs-security-intelligence/ios-url-scheme-susceptible-to-hijacking/\r\nPage 7 of 7", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "origins": [ "web" ], "references": [ "https://web.archive.org/web/20211023221110/https://blog.trendmicro.com/trendlabs-security-intelligence/ios-url-scheme-susceptible-to-hijacking/" ], "report_names": [ "ios-url-scheme-susceptible-to-hijacking" ], "threat_actors": [ { "id": "75108fc1-7f6a-450e-b024-10284f3f62bb", "created_at": "2024-11-01T02:00:52.756877Z", "updated_at": "2026-04-10T02:00:05.273746Z", "deleted_at": null, "main_name": "Play", "aliases": null, "source_name": "MITRE:Play", "tools": [ "Nltest", "AdFind", "PsExec", "Wevtutil", "Cobalt Strike", "Playcrypt", "Mimikatz" ], "source_id": "MITRE", "reports": null } ], "ts_created_at": 1775434108, "ts_updated_at": 1775826681, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/e8aa983cd7a4e4d0e9bd8e5df148a9a893576633.pdf", "text": "https://archive.orkl.eu/e8aa983cd7a4e4d0e9bd8e5df148a9a893576633.txt", "img": "https://archive.orkl.eu/e8aa983cd7a4e4d0e9bd8e5df148a9a893576633.jpg" } }