{ "id": "bc726cb0-45d5-4e5d-ad9f-1feb3cbcc3f8", "created_at": "2026-04-06T00:06:24.742644Z", "updated_at": "2026-04-10T13:12:06.134899Z", "deleted_at": null, "sha1_hash": "efb94df5010b2c95650d2b16da6c8e316bdabefb", "title": "How we protect users from 0-day attacks", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 63949, "plain_text": "How we protect users from 0-day attacks\r\nBy Maddie Stone\r\nPublished: 2021-07-14 · Archived: 2026-04-05 22:28:54 UTC\r\nJul 14, 2021\r\n8 min read\r\nM\r\nMaddie Stone\r\nThreat Analysis Group\r\nC\r\nClement Lecigne\r\nThreat Analysis Group\r\nZero-day vulnerabilities are unknown software flaws. Until they’re identified and fixed, they can be exploited by attackers.\r\nGoogle’s Threat Analysis Group (TAG) actively works to detect hacking attempts and influence operations to protect users\r\nfrom digital attacks, this includes hunting for these types of vulnerabilities because they can be particularly dangerous when\r\nexploited and have a high rate of success.\r\nIn this blog, we’re sharing details about four in-the-wild 0-day campaigns targeting four separate vulnerabilities we’ve\r\ndiscovered so far this year: \r\nCVE-2021-21166 and CVE-2021-30551 in Chrome,\r\nCVE-2021-33742 in Internet Explorer, and\r\nCVE-2021-1879 in WebKit (Safari).\r\nThe four exploits were used as a part of three different campaigns. As is our policy, after discovering these 0-days, we\r\nquickly reported to the vendor and patches were released to users to protect them from these attacks. We assess three of\r\nthese exploits were developed by the same commercial surveillance company that sold these capabilities to two different\r\ngovernment-backed actors. Google has also published root cause analyses (RCAs) on each of the 0-days.\r\nIn addition to the technical details, we’ll also provide our take on the large uptick of in-the-wild 0-day attacks the industry is\r\nseeing this year. Halfway into 2021, there have been 33 0-day exploits used in attacks that have been publicly disclosed this\r\nyear — 11 more than the total number from 2020. While there is an increase in the number of 0-day exploits being used, we\r\nbelieve greater detection and disclosure efforts are also contributing to the upward trend.\r\nChrome: CVE-2021-21166 and CVE-2021-30551\r\nOver the past several months, we have discovered two Chrome renderer remote code execution 0-day exploits, CVE-2021-\r\n21166 and CVE-2021-30551, which we believe to be used by the same actor. CVE-2021-21166 was discovered in February\r\nhttps://blog.google/threat-analysis-group/how-we-protect-users-0-day-attacks/\r\nPage 1 of 5\n\n2021 while running Chrome 88.0.4323.182 and CVE-2021-30551 was discovered in June 2021 while running Chrome\r\n91.0.4472.77.\r\nBoth of these 0-days were delivered as one-time links sent by email to the targets, all of whom we believe were in Armenia.\r\nThe links led to attacker-controlled domains that mimicked legitimate websites related to the targeted users. When a target\r\nclicked the link, they were redirected to a webpage that would fingerprint their device, collect system information about the\r\nclient and generate ECDH keys to encrypt the exploits, and then send this data back to the exploit server. The information\r\ncollected from the fingerprinting phase included screen resolution, timezone, languages, browser plugins, and available\r\nMIME types. This information was collected by the attackers to decide whether or not an exploit should be delivered to the\r\ntarget. Using appropriate configurations, we were able to recover two 0-day exploits (CVE-2021-21166 \u0026 CVE-2021-\r\n30551), which were targeting the latest versions of Chrome on Windows at the time of delivery.\r\nAfter the renderer is compromised, an intermediary stage is executed to gather more information about the infected device\r\nincluding OS build version, CPU, firmware and BIOS information. This is likely collected in an attempt to detect virtual\r\nmachines and deliver a tailored sandbox escape to the target. In our environment, we did not receive any payloads past this\r\nstage.\r\nWhile analyzing CVE-2021-21166 we realized the vulnerability was also in code shared with WebKit and therefore Safari\r\nwas also vulnerable. Apple fixed the issue as CVE-2021-1844. We do not have any evidence that this vulnerability was used\r\nto target Safari users.\r\nRelated IOCs\r\nlragir[.]org\r\narmradio[.]org\r\nasbares[.]com\r\narmtimes[.]net\r\narmlur[.]org\r\narmenpress[.]org\r\nhraparak[.]org\r\narmtimes[.]org\r\nhetq[.]org\r\nInternet Explorer: CVE-2021-33742\r\nDespite Microsoft announcing the retirement of Internet Explorer 11, planned for June 2022, attackers continue to develop\r\ncreative ways to load malicious content inside Internet Explorer engines to exploit vulnerabilities. For example, earlier this\r\nyear, North Korean attackers distributed MHT files embedding an exploit for CVE-2021-26411. These files are\r\nautomatically opened in Internet Explorer when they are double clicked by the user.\r\nIn April 2021, TAG discovered a campaign targeting Armenian users with malicious Office documents that loaded web\r\ncontent within Internet Explorer. This happened by either embedding a remote ActiveX object using a Shell.Explorer.1 OLE\r\nobject or by spawning an Internet Explorer process via VBA macros to navigate to a web page. At the time, we were unable\r\nhttps://blog.google/threat-analysis-group/how-we-protect-users-0-day-attacks/\r\nPage 2 of 5\n\nto recover the next stage payload, but successfully recovered the exploit after an early June campaign from the same actors.\r\nAfter a fingerprinting phase, similar to the one used with the Chrome exploit above, users were served an Internet Explorer\r\n0-day. This vulnerability was assigned CVE-2021-33742 and fixed by Microsoft in June 2021.\r\nThe exploit loaded an intermediary stage similar to the one used in the Chrome exploits. We did not recover additional\r\npayloads in our environment.\r\nDuring our investigation we discovered several documents uploaded to VirusTotal.\r\nBased on our analysis, we assess that the Chrome and Internet Explorer exploits described here were developed and sold by\r\nthe same vendor providing surveillance capabilities to customers around the world. On July 15, 2021 Citizen Lab published\r\na report tying the activity to spyware vendor Candiru. \r\nRelated IOCs\r\nExamples of related Office documents uploaded to VirusTotal:\r\nhttps://www.virustotal.com/gui/file/656d19186795280a068fcb97e7ef821b55ad3d620771d42ed98d22ee3c635e67/detection\r\nhttps://www.virustotal.com/gui/file/851bf4ab807fc9b29c9f6468c8c89a82b8f94e40474c6669f105bce91f278fdb/detection\r\nUnique URLs serving CVE-2021-33742 Internet Explorer exploit:\r\nhttp://lioiamcount[.]com/IsnoMLgankYg6/EjlYIy7cdFZFeyFqE4IURS1\r\nhttp://db-control-uplink[.]com/eFe1J00hISDe9Zw/gzHvIOlHpIXB\r\nhttp://kidone[.]xyz/VvE0yYArmvhyTl/GzV\r\nWord documents with the following classid:\r\n{EAB22AC3-30C1-11CF-A7EB-0000C05BAE0B}\r\nRelated infrastructure:\r\nworkaj[.]com\r\nwordzmncount[.]com\r\nWebKit (Safari): CVE-2021-1879\r\nNot all attacks require chaining multiple 0-day exploits to be successful. A recent example is CVE-2021-1879 that was\r\ndiscovered by TAG on March 19, 2021, and used by a likely Russian government-backed actor. (NOTE: This exploit is not\r\nconnected to the other three we’ve discussed above.)\r\nIn this campaign, attackers used LinkedIn Messaging to target government officials from western European countries by\r\nsending them malicious links. If the target visited the link from an iOS device, they would be redirected to an attacker-controlled domain that served the next stage payloads. The campaign targeting iOS devices coincided with campaigns from\r\nthe same actor targeting users on Windows devices to deliver Cobalt Strike, one of which was previously described by\r\nVolexity.\r\nAfter several validation checks to ensure the device being exploited was a real device, the final payload would be served to\r\nexploit CVE-2021-1879. This exploit would turn off Same-Origin-Policy protections in order to collect authentication\r\ncookies from several popular websites, including Google, Microsoft, LinkedIn, Facebook and Yahoo and send them via\r\nhttps://blog.google/threat-analysis-group/how-we-protect-users-0-day-attacks/\r\nPage 3 of 5\n\nWebSocket to an attacker-controlled IP. The victim would need to have a session open on these websites from Safari for\r\ncookies to be successfully exfiltrated. There was no sandbox escape or implant delivered via this exploit. The exploit\r\ntargeted iOS versions 12.4 through 13.7. This type of attack, described by Amy Burnett in Forget the Sandbox Escape:\r\nAbusing Browsers from Code Execution, are mitigated in browsers with Site Isolation enabled such as Chrome or Firefox. \r\nRelated IOCs\r\nsupportcdn.web[.]app\r\nvegmobile[.]com\r\n111.90.146[.]198\r\nWhy So Many 0-days?\r\nThere is not a one-to-one relationship between the number of 0-days being used in-the-wild and the number of 0-days being\r\ndetected and disclosed as in-the-wild. The attackers behind 0-day exploits generally want their 0-days to stay hidden and\r\nunknown because that’s how they’re most useful. \r\nBased on this, there are multiple factors that could be contributing to the uptick in the number of 0-days that are disclosed as\r\nin-the-wild:\r\nIncrease in detection \u0026 disclosure\r\nThis year, Apple began annotating vulnerabilities in their security bulletins to include notes if there is reason to believe that a\r\nvulnerability may be exploited in-the-wild and Google added these annotations to their Android bulletins. When vendors\r\ndon’t include these annotations, the only way the public can learn of the in-the-wild exploitation is if the researcher or group\r\nwho knows of the exploitation publishes the information themselves. \r\nIn addition to beginning to disclose when 0-days are believed to be exploited in-the-wild, it wouldn’t be surprising if there\r\nare more 0-day detection efforts, and successes, occurring as a result. It’s also possible that more people are focusing on\r\ndiscovering 0-days in-the-wild and/or reporting the 0-days that they found in the wild.\r\nIncreased Utilization\r\nThere is also the possibility that attackers are using more 0-day exploits. There are a few reasons why this is likely:\r\nThe increase and maturation of security technologies and features mean that the same capability requires more 0-day\r\nvulnerabilities for the functional chains. For example, as the Android application sandbox has been further locked\r\ndown by limiting what syscalls an application can call, an additional 0-day is necessary to escape the sandbox. \r\nThe growth of mobile platforms has resulted in an increase in the number of products that actors want capabilities\r\nfor. \r\nThere are more commercial vendors selling access to 0-days than in the early 2010s.\r\nMaturing of security postures increases the need for attackers to use 0-day exploits rather than other less\r\nsophisticated means, such as convincing people to install malware. Due to advancements in security, these actors now\r\nmore often have to use 0-day exploits to accomplish their goals. \r\nConclusion\r\nOver the last decade, we believe there has been an increase in attackers using 0-day exploits. Attackers needing more 0-day\r\nexploits to maintain their capabilities is a good thing — and it  reflects increased cost to the attackers from security measures\r\nthat close known vulnerabilities. However, the increasing demand for these capabilities and the ecosystem that supplies them\r\nhttps://blog.google/threat-analysis-group/how-we-protect-users-0-day-attacks/\r\nPage 4 of 5\n\nis more of a challenge. 0-day capabilities used to be only the tools of select nation states who had the technical expertise to\r\nfind 0-day vulnerabilities, develop them into exploits, and then strategically operationalize their use. In the mid-to-late\r\n2010s, more private companies have joined the marketplace selling these 0-day capabilities. No longer do groups need to\r\nhave the technical expertise, now they just need resources. Three of the four 0-days that TAG has discovered in 2021 fall\r\ninto this category: developed by commercial providers and sold to and used by government-backed actors.\r\nMeanwhile, improvements in detection and a growing culture of disclosure likely contribute to the significant uptick in 0-\r\ndays detected in 2021 compared to 2020, but reflect more positive trends. Those of us working on protecting users from 0-\r\nday attacks have long suspected that overall, the industry detects only a small percentage of the 0-days actually being used.\r\nIncreasing our detection of 0-day exploits is a good thing — it allows us to get those vulnerabilities fixed and protect users,\r\nand gives us a fuller picture of the exploitation that is actually happening so we can make more informed decisions on how\r\nto prevent and fight it.\r\nWe’d be remiss if we did not acknowledge the quick response and patching of these vulnerabilities by the Apple, Google,\r\nand Microsoft teams. \r\nSource: https://blog.google/threat-analysis-group/how-we-protect-users-0-day-attacks/\r\nhttps://blog.google/threat-analysis-group/how-we-protect-users-0-day-attacks/\r\nPage 5 of 5", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "origins": [ "web" ], "references": [ "https://blog.google/threat-analysis-group/how-we-protect-users-0-day-attacks/" ], "report_names": [ "how-we-protect-users-0-day-attacks" ], "threat_actors": [ { "id": "38f8da87-b4ba-474b-83e6-5b04d8fb384b", "created_at": "2024-02-02T02:00:04.032871Z", "updated_at": "2026-04-10T02:00:03.532955Z", "deleted_at": null, "main_name": "Caramel Tsunami", "aliases": [ "SOURGUM", "Candiru" ], "source_name": "MISPGALAXY:Caramel Tsunami", "tools": [], "source_id": "MISPGALAXY", "reports": null } ], "ts_created_at": 1775433984, "ts_updated_at": 1775826726, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/efb94df5010b2c95650d2b16da6c8e316bdabefb.pdf", "text": "https://archive.orkl.eu/efb94df5010b2c95650d2b16da6c8e316bdabefb.txt", "img": "https://archive.orkl.eu/efb94df5010b2c95650d2b16da6c8e316bdabefb.jpg" } }