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