and they’re just as troublesome as they were before,
to the degree they’re provably being used to decide who to send malicious payloads to…
Zero-click simply highlights if the user needs to actively interact with an element to get a malicious payload - or not.
This did get me interested in the specifics of the payload, though:
“It maintains persistence via COM hijacking by overwriting a legitimate COM class registry key’s DLL path with a first-stage DLL dropped in C:\Windows\system32\IME\, and it stores encrypted second-stage payloads in the configuration directory. A signed third-party driver (physmem.sys) enables kernel-level memory access and API call proxying to avoid detection. To preserve system stability, DevilsTongue reinjects the original COM DLL during hijacking, disguising this action through shellcode manipulation of the LoadLibraryExW return value. All additional payloads are decrypted and executed only in memory, allowing the malware to steal credentials from LSASS and browsers, access Signal messages, and use browser cookies to impersonate victims on platforms like Facebook, Gmail, and VK. The malware’s use of scrubbed metadata, encryption, and unique hashes for each file further complicates detection and analysis.”
from https://www.recordedfuture.com/research/tracking-candirus-de...
Memory safety, and a number of other glaring holes in common stacks, are ignored by the general public for the same psychological and effort-related reasons that people secure their whole lives with easily-picked Schlage locks, or windows/doors that can be defeated in under 5 seconds, often silently.
Most genuinely do not or can not believe tragedy can find them - until it has.
I'm not exactly surprised that vulnerabilities like this are possible. I just wanted the details. Thank you. "WebRTC was vulnerable and allowed access to a longer exploit chain" is the important part in my view.
> Memory safety, and a number of other glaring holes in common stacks, are ignored by the general public
I would venture that "the general public" has no concept of "memory safety" in the first place.
All a game, with liabilities abstracted away to customer service and two factor texts.
But there is nothing explaining how the DLL becomes zero-click compromised by the ad.
No, their attribution is much more robust than this. Neglecting those details to oversimplify your explanation is intellectually dishonest.
> there is nothing explaining how the DLL becomes zero-click compromised [...]
They do, just a little later in that same section: "Both samples use a COM hijack for persistence [...]" through a malicious DLL.
I completely and fundamentally disagree that there is such a robust attribution. I read the section thoroughly and my explanation is not at all oversimplified. Please cite the details that you believe to be relevant here.
> They do, just a little later in that same section: "Both samples use a COM hijack for persistence [...]" through a malicious DLL.
This is not even remotely an explanation of what happened. Giving a name to a phenomenon does not explain it. This does not say how the COM hijack is effected; it does not say how any code escapes the browser sandbox at all; it does not point at a browser vulnerability. Even following through a link to their previous article, the only CVE citations they give are for local privilege escalations (which are described in a very generic way in the CVE database) which would still require a sandbox escape. And even then, it isn't necessarily relevant, as they merely claim "The functionality broadly overlaps with the functionality of the Candiru chain from our 2021 report."