Comment by zahlman
4 days ago
Awful lot of words here, but not much explanation of the actual capabilities of the "zero-click spyware". Tacking on the phrase "zero-click" suggests some kind of browser exploit, but it seems like this is just the same sort of thing as tracking cookies, third-party telemetry etc.
No, they’re using those same techniques,
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...
thank you for providing that citation; the recorded future article does provide a better explanation of the exploit details that the original post
This is still missing the point I was trying to make. Why was it possible for sandboxed JS from a webpage to interact with COM, in any way whatsoever?
The user opens a WhatsApp link (or executes a file sent to them), Chrome WebRTC is exploited, shellcode invokes a Windows Kernel race condition, process escalates to Kernel/System privileges, Windows sandbox is bypassed, allowing the malware to drop the IME DLL and initialize the COM hijacking loop.
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.
2 replies →
Keep reading:
https://citizenlab.ca/research/how-discover-tech-turned-targ...
Yes, in fact I skipped to that section. It describes targeting, and then a vague mention of ad impressions leading to "connections" to a C2 server (but the simple fact of contacting a domain doesn't establish C2; anyone can send an AJAX request anywhere). Then they describe a "fingerprint" of servers which appears to consist of... HTTP responses with several blank fields and a claim of running on Apache. Then they say that they found a compromised DLL, which they attribute to the ads based on the DLL hard-coding some domains related to the ad campaign.
But there is nothing explaining how the DLL becomes zero-click compromised by the ad.
> they attribute to the ads based on the DLL hard-coding some domains related to the ad campaign
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.
https://attack.mitre.org/techniques/T1546/015/
1 reply →