We uncover Falcon C2, a browser-based threat framework targeting governments via malicious scripts, extensions, and the Antino implant.
Source: Palo Alto Networks Unit 42 · 2026-11-11
Tag: DLL sideloading
-
Yoba Malware Hides a Crypto Miner Behind Legitimate OpenAI and Anthropic Binaries
Yoba malware uses fake ChatGPT and Claude apps to sideload malware through signed installers and deploy a cryptocurrency miner.
Check Point Research has spent two months tracking a campaign it calls Yoba, which uses the popularity of AI tools to spread a custom malware chain. The attackers build fake GitHub projects that pose as AI desktop applications such as GPT-5.6 Sol, GPT-6 Astra and Claude Opus. The projects look convincing and run on real GitHub infrastructure, which helps them seem legitimate to potential victims.
“These projects look convincing and use real GitHub infrastructure, which helps them appear legitimate to potential victims. The website exhibits search-targeted content and suspicious installer-delivery tactics consistent with an SEO-poisoning lure.
Inside the installers, there is a malicious component we refer to as the YobaDropper. This dropper includes another component, the YobaLoader, which is responsible for contacting attacker-controlled infrastructure and fetching the final payload.” reads the report. “In this report, we describe how victims are lured to these fake projects, how the YobaDropper and YobaLoader work together, and how the attackers ultimately use this chain to run unwanted software on infected systems.”
The lure is simple. Each project has a repository, a GitHub.io page describing the software, and a ZIP release with the malware. The repositories show no fake stars or forks, yet they still rank among the top Google results, most likely through SEO poisoning that optimizes titles, descriptions and hosting domains.
The first repository appeared around July 2026, but the first malicious releases landed only on August 30 and 31, and a third followed about five days later on September 4. Each repository uses a different Outlook address, and commit times point to UTC+4, UTC-4 and UTC+3, which Check Point reads as a deliberate attempt to hide the actor’s real time zone.
Here’s the trick that gives the report its title. Each ZIP holds a legitimate signed executable from OpenAI or Anthropic, named Setup.exe, next to a malicious winmm.dll. The signed program loads the DLL on its own, a technique known as DLL sideloading, which is often used to bypass security protections.
The ZIP files were not even password-protected. Attackers often use passwords to prevent security tools from automatically unpacking and scanning files. However, these binaries already had very low detection rates because they used anti-sandbox and other techniques to avoid analysis. The DLL’s compilation date is another clue: it was built on the same day it was added to the archive, unlike the legitimate files around it.
The dropper, called YobaDropper, checks the environment before running. It calculates a hash of the name of the program that launched it and continues only if the name is Setup.exe. This means that sandboxes that run the DLL on its own will fail this check. When that happens, the process does not exit. Instead, it sleeps 200,000 times for 5.5 seconds each, a total of about 12.73 days.
The malware also avoids victims in CIS countries by checking the keyboard layout. It excludes Russian, Belarusian, Tajik, Armenian, Azerbaijani, Georgian, Kazakh, Kyrgyz, Turkmen, Uzbek, and Tatar. Interestingly, Ukraine, which has often appeared in similar exclusion lists, is not included.
Next, the malware requests administrator privileges. If the user does not have them, it displays the message “Please run this program as Administrator.” and exits. The victim must then restart it with administrator rights.
Once it has the required privileges, the malware creates a folder called WMProcess under ProgramData. It copies the legitimate WMPDMC.exe file from System32 into this folder and places the second-stage payload there under the name wmpdui.dll.
The malicious code achieves persistence by using a scheduled task dressed up as Microsoft. The author is set to Microsoft Corporation, the description says it collects device metadata for Windows Media Player, and it starts three minutes after boot as Local System. The task launches the legitimate program, which sideloads the malicious DLL.
The second stage, YobaLoader, shares code with the dropper, which points to the same developer. It only runs under WMPDMC.exe and uses a different seed for its hashing than the dropper does, which separates the stages and weakens hash-based detection. Its job is to find its payload without a classic command server.
It goes to a Telegram channel, t[.]me/yoba_fanclub, and downloads the channel’s profile picture. The last 50 bytes of the image seed a domain generator that builds names from word lists in the form adjective-noun-verb-number on dedyn[.]io. Change the picture and the operator gets a new domain.
Then it asks Google’s DNS-over-HTTPS service for a TXT record on that domain. The reply is signed, and the loader checks the signature before decrypting it, which gives a link to a payload on Catbox. Check Point says this reliance on DoH and common hosting aims to bypass passive DNS monitoring and some gateway protections, and the campaign avoids dedicated command-and-control infrastructure, using Telegram, Tor, Catbox and DoH instead.
The operator can choose how the payload runs. It can inject it into svchost.exe, save it as an executable after removing the Zone.Identifier mark, or run it as a hidden PowerShell script while bypassing execution policies.
“Finally, the injected payload into
svchost.exeis an XMRig 6.26.0 miner with a hidden command line targeting a TLS-enabled onion mining endpoint through a local Tor SOCKS5 proxy. It can unpack and start Tor 0.4.9.12 plus lyrebird 0.8.1, monitor user-input activity to pause mining, and conditionally load the WinRing0 driver service for MSR-based mining optimization.” continnues the report.The miner uses Tor to connect to an encrypted mining server. It can start its own Tor components, use about 85% of CPU threads, and pause mining when the user is active. It resumes after 240 seconds of inactivity and can load the WinRing0 driver to optimize mining performance.
However, YobaLoader is not limited to cryptocurrency mining. Its DNS tasking system allows operators to deliver any PE executable or PowerShell payload, meaning future attacks could distribute other malware families.
Earlier versions appeared in June 2026. They used Cursor.exe for sideloading, a startup shortcut for persistence, and excluded only Russia. They also used .aber[.]ir instead of dedyn[.]io and included anti-debugging and anti-VM checks that later versions dropped.
Check Point believes the attackers may have Russian origins and mainly operate in the UTC-4 time zone, but this is an assessment, not a confirmed attribution.
Defenders should look for suspicious WMPDMC.exe copies under ProgramData, fake Microsoft scheduled tasks, Telegram-related traffic, DNS lookups for dedyn[.]io through dns.google, and unexplained high CPU usage.
“The Yoba campaign shows how attackers can use trusted platforms and the current interest in AI tools to distribute malware in a way that looks believable and harmless at first glance. By packaging their code together with well-known software names and hosting it on GitHub, they lower the chances that users or basic security checks will immediately flag the files as suspicious.” concludes the report. “Organizations should be cautious about installing “AI helpers” or similar tools from unverified repositories and should enforce policies that restrict running software from unknown sources. Combining user awareness with basic technical controls.”
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, Yoba malware)
Source: Security Affairs · 2026-10-30
-
How APT41 revived the BlackLotus bootkit to attack diplomatic organizations in Central Asia
Introduction
Back in October 2022, Kaspersky GReAT was looking into a peculiar advertisement on a hacking forum. A cybercriminal had been advertising a UEFI bootkit, dubbed BlackLotus, that could bypass Secure Boot, for $5,000. Given the low price for such powerful capabilities, the cybersecurity community initially took this advertisement with a grain of salt. As no BlackLotus samples were found in the wild, no one could at the time verify the claims made in the forum post.
BlackLotus advertisement
However, about half a year later, in March 2023, ESET confirmed that the BlackLotus advertisement was genuine. The researchers tracked down samples of this bootkit and confirmed that it can indeed bypass Secure Boot through a vulnerability called Baton Drop (CVE-2022-21894). As this vulnerability was still exploitable in 2023, Microsoft had to release multiple security updates to address it.
Since the release of these updates, the BlackLotus bootkit has gone quiet — no publicly known attacks have used it. Yet in early 2026, we discovered a malware sample similar to BlackLotus that was used in an APT campaign in Central Asia. In this report, we share our findings, including new payloads and possible attribution of this campaign.
The return of the infamous bootkit
In early 2026 we identified a complex APT attack targeting diplomatic agencies in Central Asian countries — namely Tajikistan, Uzbekistan, and Turkmenistan. This attack involved a UEFI bootkit that we dubbed BlackX. Having examined it, we found it to be similar to BlackLotus.
Attackers have been deploying BlackX after compromising the victim machine networks and obtaining administrator privileges. To install the bootkit, we observed them dropping the following files:
inst.exe, an installer executablePVMDIJGKAX2, an RC4-encrypted extensionless file containing files and strings required for the installation
The installer was launched with the command line
C:\ProgramData\Intel\inst.exe PVMDIJGKAX2 Q46F6MDLI3RX2KV1. The last argument here is the RC4 key used for decryption.Curiously, the file
inst.exedoes not contain any malicious strings or embedded blobs. All the files needed to install the malicious payload are insidePVMDIJGKAX2, which makes it harder for incident responders to retrieve the bootkit components.The installer package drops a set of files to both system and UEFI partitions, designed to exploit the Baton Drop vulnerability. We noted that the implementation of the exploit is remarkably similar to the one used in the BlackLotus malware. As with BlackLotus, the goal of the exploit is to install custom Machine Owner Keys (MOK), which allows loading arbitrary EFI files on the target machines to manipulate Secure Boot.
While the vulnerability exploitation chain was implemented very similarly to BlackLotus, we spotted differences between the exploits in BlackLotus and BlackX. That said, the source code of the BlackLotus bootkit has never been published online. This could mean that the attackers behind BlackX either reverse-engineered the BlackLotus bootkit or purchased its source code from cybercriminals. Either way, this is an interesting observation, as we rarely see APT actors borrow ideas or code from cybercrime actors.
Payload launched by the bootkit
The UEFI payload delivered during the Baton Drop exploitation has a classic bootkit goal — to inject a malicious driver into the Windows kernel. This driver differs from the one deployed by BlackLotus and is signed with a certificate belonging to an organization named 温江区明宇网络技术服务工作室 (English: Wenjiang District Mingyu Network Technology Service Studio). At the time of writing, this certificate (serial number: 0bcdf5e0da32d68900b8b7638459d072) has been revoked by its issuer.
The driver aims to tamper with security solutions installed on the machine. For example, it disables process, thread, and registry callbacks related to security solutions. It also tampers with ETW providers so that security solutions cannot access their output. Curiously, some of the tampering procedures are designed to run only if Kaspersky or Avast solutions are installed on the infected machine. However, during dynamic analysis of this driver, we found that these procedures are useless — they fail to interfere with Kaspersky products in any way.
The driver also protects the bootkit’s files from tampering. It intercepts kernel requests to open these files and returns a handle to
calc.exeinstead of a malicious file handle.User-mode second-stage payloads
Apart from tampering with security solutions, the driver also deploys a user-mode payload. We observed two such payloads, used for cyberespionage, in the wild. One of them is a RAT that can load further-stage .NET payloads. This RAT uses cloud storage for C2 server communications — we observed its versions using Google Drive, OneDrive, and Yandex.Disk. Having connected to a cloud storage service, this RAT iterates over files available there and interprets them depending on the file suffix. Below is a list of supported suffixes:
File suffix Description Type 0X01 A .NET file. The task is to parse it and run the method TEST.Class1.RunCMD(argument_array) from the module Input 0X02 Result of the call TEST.Class1.RunCMD(argument_array) Output 0X03 Task to upload a file to the drive Input 0X04 Uploaded file Output 0X05 Task to download a file to an infected machine Input 0X06 File download status Output SSSR Contains initial system info Output We also observed another payload delivered through the bootkit, which we dubbed OxiDLLRunner. It is a malicious DLL obfuscated with OLLVM. It is loaded by the legitimate file
googleupdate.exe(original filename:jcef_helper.exe, MD5: AF8A983B9ADA07EAE1259BF2953ABD40), which is also delivered by the bootkit. The DLL decrypts the contents of the filev8_context_snapshot.bin, which resides in the same folder, and then jumps to the beginning of the decrypted content. The decrypted data starts with shellcode followed by a PE file, which is a Rust payload designed to communicate with thewww[.]archivetj[.]comC2 server. During communication, this payload is supposed to receive DLL files exporting a function namedcreate_plugin, which are then executed in separate threads.Attribution
Based on the following facts, we have attributed this attack to the APT41 threat actor with medium confidence:
- In June 2026, ESET published a blog post on attacks by the FishMonger threat actor, which the community assumes to be related to APT41. This post describes a kernel implant with a PDB path starting with C:\Users\xdd\Desktop. While describing the campaign, the post also suggests the possible use of an unspecified UEFI bootkit component, which might exploit CVE‑2023‑24932. We observed the identifier “xdd” used multiple times in the BlackX bootkit payloads, so we assess that BlackX is the UEFI bootkit referenced in the ESET blog post;
- The payloads deployed by BlackX are loaded using a legitimate executable abused via DLL sideloading, and an encrypted file — this pattern is common among Chinese-speaking threat actors;
- The OxiDLLRunner file has been obfuscated with OLLVM, an obfuscator commonly used by Chinese-speaking actors.
Why did the target organizations get infected?
During our initial analysis of BlackX, we thought that attackers succeeded in deploying it due to the negligence of the target organizations. Baton Drop, the vulnerability used to deploy BlackX, was disclosed back in 2023 and was patched, so we first thought that the infected machines lacked the relevant updates. However, our investigation proved this wrong — the targeted machines were fully patched.
Instead, we found out that the problem was with the patch itself. As it turned out, the patch for the Baton Drop vulnerability is designed to revoke the “Windows Production PCA 2011” certificate used to sign vulnerable UEFI components. However, this revocation does not happen automatically upon patch installation — the user has to trigger it manually. This is done with the following steps:
- A registry flag is set inside HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot;
- A scheduled task named Secure-Boot-Update is created.
This patch is designed to be applied manually — for instance, applying it automatically could break dual-boot systems relying on the “Windows Production PCA 2011” certificate to load. At the same time, this patch deployment practice creates a problem — as it is extremely unusual for a system administrator to take extra steps after installing an update. Usually, when applying patches, system administrators take no further action unless an installation failure occurs. These instructions for activating the patch are buried deep on the Microsoft website, and we assess that they are quite hard for an average IT administrator to notice.
Curiously, Microsoft’s plan for deploying the Baton Drop patches mentions an “Enforcement Phase” that involves revoking the “Windows Production PCA 2011” certificate automatically, without user interaction. At the time of publishing this post, this stage has not been implemented. On October 19, 2026, this certificate expired, but this does not prevent the vulnerable binaries from loading unless the certificate is blocklisted.
It is likely that the threat actor behind this campaign took into account that few organizations realized the importance of manually activating the Baton Drop patch. As such, we believe they decided to invest time in understanding how BlackLotus works and creating a copycat of this bootkit.
Conclusion
Patch management is important for every organization, as updates from vendors help protect software and hardware against known vulnerabilities. However, sometimes installed patches fail to protect against the flaws they address. The BlackLotus story we described is not the only such example — for instance, in 2025 Microsoft released an update against the ToolShell vulnerability that also had to be applied manually.
However, modern security solutions are designed to account for such cases when installed patches fail to protect against security flaws for one reason or another. For instance, the Exploit Prevention component available in Kaspersky products prevents exploits from running if the patch is not applied, or if it is a zero-day vulnerability with no available patch. It is thus crucial to equip all machines in an organization with security solutions and constantly monitor the alerts they raise.
Source: Securelist (Kaspersky GReAT) · 2026-10-22
