2026-05-23 AI创业新闻

First VPN Dismantled in Global Takedown Over Use by 25 Ransomware Groups

Authorities in Europe and North America have announced the dismantling of a criminal virtual private network (VPN) service used by criminal actors to obscure the origins of ransomware attacks, data theft, scanning, and denial-of-service attacks. Codenamed Operation Saffron, the disruption of First VPN Service was led by France and the Netherlands, with several other nations supporting the investigation since December 2021, including Luxembourg, Romania, Switzerland, Ukraine, the U.K., Canada, Germany, the U.S., Spain, Sweden, Denmark, Estonia, Latvia, Lithuania, Poland, and Portugal. First VPN, per Europol , offered services designed specifically for criminal use, allowing anonymous payments and a hidden infrastructure that enabled paying customers to hide their identities when carrying out ransomware attacks, large-scale fraud, and data theft. It was promoted on Russian-speaking cybercrime forums such as Exploit[.]in and XSS[.]is as a tool to evade law enforcement.

The international operation took place between May 19 and 20, during which authorities took a series of concurrent actions that involved interviewing the service’s administrator, conducting a house search in Ukraine, taking down 33 servers, and seizing infrastructure used to support cybercriminal activity globally. The names of confiscated domains are listed below - 1vpns[.]com 1vpns[.]net 1vpns[.]org Related onion domains operating on the Tor network “First VPN’s website promoted itself by emphasizing anonymity, promising its users that it would not cooperate with any judicial authority, that it would not store data, and that the service would not be subject to any jurisdiction,” Eurojust said . Europol also said First VPN’s users have been notified of the shutdown and warned that their identities are now known to authorities. Bitdefender, which supported the investigation through Europol and shared information linked to 506 users, said disrupting anonymization services raises the cost of operation across the cybercriminal ecosystem.

“New anonymization services will appear. The economic demand hasn’t changed. But each takedown shortens the operational window of the next service and raises the barrier for actors who relied on turnkey solutions,” the Romanian cybersecurity company said . “First VPN advertised itself as a service criminals could trust to keep them beyond law enforcement’s reach.

The operation proved that claim wrong, and every actor evaluating the next anonymization service now knows the same risk exists.” In a coordinated flash alert, the U.S. Federal Bureau of Investigation (FBI) said the service has been active since about 2014, providing 32 exit node servers in 27 countries. Three of the exit nodes were located in the U.S. - 2.223.66[.]103 5.181.234[.]59 92.38.148[.]58 Other exit nodes were located in Australia, Austria, Belgium, Canada, Cyprus, Finland, France, Germany, Hong Kong, Italy, Latvia, Luxembourg, Moldova, the Netherlands, Panama, Poland, Romania, Russia, Serbia, Singapore, Spain, Sweden, Switzerland, Turkey, Ukraine, and the U.K.

No less than 25 ransomware groups, such as Avaddon Ransomware, are said to have used First VPN infrastructure to perform network reconnaissance and intrusions. The subscription duration ranged anywhere from one day to one year. Based on the subscription plan, they cost between $2 for a single day and $483 for a whole year. It accepted payments through Bitcoin, Perfect Money, Webmoney, EgoPay, and InterKass.

“First VPN Service offered several connection protocols, including OpenConnect, WireGuard, Outline, and VLess TCP Reality, and multiple encryption options including OpenVPN ECC, L2TP/IPSec, and PPtP,” the FBI said . “Technical support was also offered to users via a self-hosted Jabber server and Telegram encrypted messaging service. Among the VPN protocol options, First VPN Service offered ‘VLESS’ and ‘Reality’ which provides the ability to disguise VPN Internet traffic as HTTPS traffic over ports which are commonly used to connect to websites.” According to snapshots captured on the Internet Archive, First VPN offered “Anonymity, Stability, Security,” stating “We do not store any logs that would allow us or third parties to associate an IP address in a specific period of time with the user of our service.” “The only data we store is e-mail and username, but it’s impossible to connect the user’s activity on the Internet with a specific user of our service,” it added. As a way to escape liability, First VPN also noted in its FAQ that it “strictly” prohibited the use of its servers for illicit activities.

“This facilitates the receipt of complaints about our servers, and as a result, they will be disabled,” read the FAQ. Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Ghostwriter Targets Ukraine Government Entities with Prometheus Phishing Malware

The Belarus-aligned threat actor known as Ghostwriter (aka UAC-0057 and UNC1151Ukraine’s National Security and Defense Council) has been observed using lures related to Prometheus, a Ukrainian online learning platform, to target government organizations in the country. The activity, per the Computer Emergency Response Team of Ukraine (CERT-UA), involves sending phishing emails to government entities using compromised accounts. It’s been active since the spring of 2026. “Typically, the email contains a PDF attachment with a link that, when clicked, leads to the download of a ZIP archive containing a JavaScript file,” the agency said in a Thursday report.

The JavaScript file, dubbed OYSTERFRESH, is designed to display a decoy document as a distraction mechanism, while stealthily writing an obfuscated and encrypted payload called OYSTERBLUES to the Windows Registry, as well as downloading and launching OYSTERSHUCK, which is responsible for decoding OYSTERBLUES. OYSTERBLUES is equipped to harvest a wide range of system information, including computer name, user account, OS version, time of the last OS boot, and a list of running processes. The collected data is sent to a command-and-control (C2) server over an HTTP POST request. It then awaits further responses containing next-stage JavaScript code, which is executed using the eval() function .

The final payload is assessed to be Cobalt Strike, an adversary simulation framework that’s widely abused for post-exploitation activities. “To reduce the likelihood of this cyber threat being exploited, it is advisable to apply known basic approaches to reducing the attack surface, specifically by restricting the ability to run wscript.exe for standard user accounts,” CERT-UA said. The disclosure comes as Ukraine’s National Security and Defense Council revealed Russia’s use of artificial intelligence (AI) tools like OpenAI ChatGPT and Google Gemini to scout targets and embed the technology into malware to generate malicious commands at runtime, while calling out Kremlin-backed hacking groups for carry out cyber attacks focused on obtaining intelligence and ensuring a long-term presence in compromised networks for follow-on exploitation, including to support influence operations. “The main vectors of initial penetration in 2025 were social engineering, exploitation of vulnerabilities, use of compromised RDP and VPN accounts, attacks on supply chains, and the use of unlicensed software that already contains built-in backdoors at the installation stage,” the Council said.

“Attackers focused on stealing sensitive information, intercepting communications, and tracking the location of targets.” In a related development, details have emerged about a pro-Kremlin propaganda campaign that hijacked real Bluesky users’ accounts to post fake content since 2024. Hijacked accounts included journalists and professors. The activity has been attributed to a Moscow-based company called Social Design Agency , which is linked to a campaign known as Matryoshka. In some of these cases, Bluesky has taken the step of suspending the accounts until the owners initiate a reset.

Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Megalodon GitHub Attack Targets 5,561 Repos with Malicious CI/CD Workflows

Cybersecurity researchers have disclosed details of a new automated campaign called Megalodon that has pushed 5,718 malicious commits to 5,561 GitHub repositories within a six-hour window. “Using throwaway accounts and forged author identities (build-bot, auto-ci, ci-bot, pipeline-bot), the attacker injected GitHub Actions workflows containing base64-encoded bash payloads that exfiltrate CI secrets, cloud credentials, SSH keys, OIDC tokens, and source code secrets to a C2 server at 216.126.225[.]129:8443,” SafeDep said in a report. The complete list of data harvested by the malware is below - CI environment variables, /proc/*/environ, and PID 1 environment Amazon Web Services (AWS) credentials Google Cloud access tokens Instance role credentials obtained by querying AWS IMDSv2, Google Cloud metadata, and Microsoft Azure Instance Metadata Service (IMDS) endpoints SSH private keys Docker and Kubernetes configurations Vault tokens Terraform credentials Shell history API keys, database connection strings, JWTs, PEM private keys, and cloud tokens matching more than 30 secret regular expression patterns GitHub Actions OIDC token request URL and token GITHUB_TOKEN, GitLab CI/CD tokens, and Bitbucket tokens .env files, credentials.json, service-account.json, and other configuration files One of the impacted packages is @tiledesk/tiledesk-server, which bundles a Base64-encoded bash payload within a GitHub Actions workflow file. In all, 5,718 commits were pushed against 5,561 distinct repositories on May 18, 2026, between 11:36 a.m.

and 5:48 p.m. UTC. “The attacker rotated through four author names (build-bot, auto-ci, ci-bot, pipeline-bot) and seven commit messages, all mimicking routine CI maintenance,” SafeDep said. “The attacker used throwaway GitHub accounts with random 8-character usernames (e.g., rkb8el9r, bhlru9nr, lo6wt4t6), set git config to forge the author identity, and pushed via compromised PATs or deploy keys.” Two payload variants have been observed as part of the large-scale campaign: SysDiag, a mass variant which adds a new workflow that’s triggered on every push and pull request, and Optimize-Build, a targeted variant that activates only on workflow_dispatch , a GitHub Actions trigger that allows users to manually run a workflow on-demand.

In the case of Tiledesk, the targeted approach is used to target CI/CD runners, and not when the npm package is installed. “The tradeoff is reach: on: push would guarantee execution on every commit to master, hitting more targets without intervention,” SafeDep added. “Workflow_dispatch sacrifices that for operational security. With 5,700+ repos compromised, even a small fraction yielding a usable GITHUB_TOKEN gives the attacker enough targets for on-demand triggering.” The result is that once a repository owner merges the commit, the malware executes inside their CI/CD pipelines and spreads further, enabling the theft of credentials and secrets at scale.

“We’ve entered a new supply chain attack era, and TeamPCP compromising GitHub was only the beginning,” OX Security’s Moshe Siman Tov Bustan said . “What’s coming next is an endless wave, a tsunami of cyber attacks on developers worldwide.” The development comes as TeamPCP has weaponized the interlinked software supply chain to corrupt hundreds of open-source tools, worming their way through several ecosystems and extorting victims for profit in some cases. Microsoft-owned GitHub has become the latest addition to the group’s long list of victims, which also includes TanStack, Grafana Labs, OpenAI, and Mistral AI. TeamPCP attacks have fueled a cyclical exploitation of popular open-source projects, where one compromise feeds the next, allowing the malware to spread like wildfire in a worm-like fashion.

The group also appears to be financially motivated and has established partnerships with BreachForums and other extortion crews like LAPSUS$ and VECT. What’s more, the group seems to be geopolitically motivated as well, as evidenced by the deployment of wiper malware upon detecting machines located in Iran and Israel. The fallout from TeamPCP’s attack spree and the Mini Shai-Hulud worm has prompted npm to invalidate granular access tokens with write access that bypasses two-factor authentication (2FA). NPM is also urging users to switch to Trusted Publishing to reduce reliance on such tokens.

“By burning every bypass-2FA token on the platform, npm cuts off the credentials the worm has already collected,” application security firm Socket said . “Maintainers issue new ones. The worm, still active in the wild, goes back to harvesting them. The reset buys breathing room.

It does not close the underlying hole.” Activity clusters like Megalodon and TeamPCP involve compromising legitimate packages to distribute malware. In contrast, a throwaway account named “ polymarketdev “ has been found to publish nine malicious npm packages impersonating Polymarket trading CLI tools within a 30-second window to steal victims’ Ethereum/Polygon private keys via a postinstall hook. As of writing, they are still available for download from npm. The names of the packages are below - polymarket-trading-cli polymarket-terminal polymarket-trade polymarket-auto-trade polymarket-copy-trading polymarket-bot polymarket-claude-code polymarket-ai-agent polymarket-trader “On install, a postinstall script displays a fake wallet onboarding prompt that asks the user to paste their private key, claiming ‘it stays encrypted,’” SafeDep said .

“The script POSTs the raw key in plaintext to a Cloudflare Worker at hxxps://polymarketbot.polymarketdev.workers[.]dev/v1/wallets/keys.” “The attacker built a functional trading CLI around a credential theft operation. Social engineering carries the attack: the postinstall prompt looks like standard wallet onboarding, the masking mimics secure input, and the GitHub repo provides false credibility” Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Military Appreciation Month: 10% Off SANS Cybersecurity Training

Making Vulnerable Drivers Exploitable Without Hardware - The BYOVD Perspective

1 Introduction This article provides a technical analysis of how many Windows kernel mode drivers can be interacted with from user mode without the hardware they were developed for. This work was motivated by driver-oriented vulnerability research and the need to evaluate the exploitability of individual findings, which frequently affect code whose reachability is hardware-gated. The methodology presented here should help anyone determine whether a particular Windows kernel mode driver vulnerability remains reachable - and thus potentially exploitable - even in the absence of the hardware the driver was developed for. The reader is expected to have basic Windows driver knowledge, especially regarding device objects.

The rest of this article is written with the assumption that the reader is already familiar with the concepts described in the introduction article: Anatomy of Access: Windows Device Objects from a Security Perspective . Just like the introduction article, this resource is not focused on any specific bug class, but rather the attack surface and, to an extent, the Windows Plug and Play architecture. All the tests demonstrated here were conducted on Windows 11 23H2 (winver 10.0.22631.3007). For more such latest threat research and vulnerability advisory, please subscribe to Atos Cyber Shield blogs.

2 The offensive value of kernel mode drivers In addition to the obvious Local Privilege Escalation potential, vulnerable drivers are often abused in BYOVD attacks - a post-exploitation technique leveraged by attackers to disrupt system defenses such as EDR components. Two main criteria determine whether a driver vulnerability is a strong candidate for BYOVD attacks: 1. Exploitation allows meaningful disruption of an otherwise tamper-resistant security component. Examples include kernel-level vulnerabilities granting arbitrary memory read/write access, arbitrary code execution, or arbitrary resource abuse (e.g., overwriting files, closing handles, or terminating processes).

1. Its exploitability is independent of rare system conditions, such as the presence of specific hardware. Although BYOVD-style attacks have been well documented for years, with numerous public reports and research papers on the topic (e.g. https://www.ndss-symposium.org/wp-content/uploads/2026-s1491-paper.pdf , https://blackpointcyber.com/blog/qilin-ransomware-and-the-hidden-dangers-of-byovd/ , https://www.sophos.com/en-us/blog/itll-be-back-attackers-still-abusing-terminator-tool-and-variants ), none of them specifically examines the role of hardware-gating in driver vulnerability reachability.

3 Device object creation and maintenance - common patterns The analysis provided in this resource is structured around device objects, because they are the most viable attack vector. However, the techniques demonstrated here practically impact driver code reachability from userland in general, not just via IRP. The most common obstacles in attacking a driver via its device object are: 1. The device object is not created.

1. The driver’s internal state does not allow the exercise of the vulnerable behavior despite the device object being accessible. Both scenarios are very common when dealing with a device driver deployed on a system without the corresponding physical hardware. In the rest of the article I am often referring to device stacks and device nodes .

I have covered device stacks quite broadly in my introduction article . While a device node and a device stack are not the same thing, the terms are often used interchangeably, because every device node has exactly one device stack. 3.1 Unconditional creation upon driver load Many drivers, especially non-PnP drivers, create their device objects either directly from within their DriverEntry function, or from some other function that gets invoked in the direct call chain originating from DriverEntry. Multidev_WDM demo driver exemplifies this pattern.

We can see the device creation invoked right away in DriverEntry: CDO creation invoked directly from DriverEntry The driver also removes the device object by calling IoDeleteDevice, but that happens only when DriverUnload is called (when the driver is being unloaded): CDO cleanup from DriverUnload Drivers built this way can be interacted with after simple deployment consisting of just two steps: Create the driver’s service entry: sc.exe create SampleDrv type= kernel start= demand binPath= System32\drivers\SampleDrv.sys sc.exe create SampleDrv type= kernel start= demand binPath= System32\drivers\SampleDrv.sys Start the service (driver will load): sc.exe start SampleDrv If we look at a randomly picked driver from https://loldrivers.io/, we will see that its deployment command matches this pattern: LOL drivers - zam64.sys deployment But most device drivers do not fall into this category, as we will see in the following sections of this article. 3.2 Conditional device creation and maintenance Oftentimes driver initialization routines perform additional checks. For example, kernel mode components of security software (EDR, anti-virus, monitoring, enhanced authentication etc.) tend to check for product-specific registry keys and entries, which are created and initialized during normal product deployment. Actual device drivers (created to drive physical hardware) tend to only create their device objects in the presence of that hardware.

Without it they either: - do not attempt to create any device objects at all, - they remove any device objects shortly after their creation, by calling IoDeleteDevice. Let’s focus on how that logic is implemented and evaluate whether and how it can be worked around, especially from the BYOVD perspective - by solely operating from userland (with no physical/hypervisor access). By the way, the second scenario, in which a device object is first created and then deleted shortly after, creates a situation that could be considered a race condition, because there is a short time window in which the device object exists. 3.3 PnP-specific callbacks as the main location of PnP driver initialization logic In PnP-compatible drivers (which make up most of device drivers), initialization logic extends beyond DriverEntry into the following PnP-specific routines: AddDevice and the IRP_MJ_PNP handler.

This section explores both of them and explains why most PnP-compatible drivers need to be set up in a way that ensures these functions are called if we want to interact with the driver. 3.3.1 AddDevice All PnP-compatible drivers must define this routine. It is responsible for creating functional device objects (FDO) and filter device objects (filter DO) for devices enumerated by the PnP manager. This explains why AddDevice is where most of the initialization logic resides.

That includes: - creation of device objects (IoCreateDevice), - initialization of various internal variables that are later required to reach the vulnerable code, - I/O queue management in WDF (KMDF) drivers. The MSDN page about managing I/O queues in WDF drivers says: > Drivers typically call WdfIoQueueCreate from within an EvtDriverDeviceAdd callback function. The framework can begin delivering I/O requests to the driver after the driver’s EvtDriverDeviceAdd callback function returns. In the context of WDF (KMDF) drivers, AddDevice is referred to as EvtDriverDeviceAdd (different name, same application).

AddDevice is not called from within the DriverEntry routine, which means it does not automatically execute upon driver load. Instead, the PnP manager invokes it only after it discovers a new device node and determines that this driver should either control the device directly or serve as a filter in the device stack. Let’s look at some code. Note: all structure-specific offsets are for the 64-bit architecture.

Both in DriverEntry and in AddDevice, the first parameter the function receives is a pointer to the DRIVER_OBJECT structure . As we can read on the MSDN page, the structure is allocated by the I/O manager: The I/O manager allocates the DRIVER_OBJECT structure and passes it as an input parameter to a driver’s DriverEntry, AddDevice, and optional Reinitialize routines and to its Unload routine, if any. DRIVER_OBJECT contains pointers to the driver’s dispatch routines, each at a specific offset (e.g. 0xe0 for IRP_MJ_DEVICE_CONTROL).

The pointer to AddDevice, however, is not stored directly in the DRIVER_OBJECT structure, but in the DRIVER_EXTENSION structure, accessed via DriverObject->DriverExtension->AddDevice. This fact is mentioned on the same MSDN page : Pointer to the driver extension. The only accessible member of the driver extension is DriverExtension->AddDevice, into which a driver’s DriverEntry routine stores the driver’s AddDevice routine. So in the decompiler, the AddDevice assignment typically looks like: // DriverObject->DriverExtension->AddDevice = SomeFunction; ((param_1 + 0x30) + 8) = FUN_XXXXX; So, a typical initialization sequence for driver dispatch routines and other standard callbacks we can usually find in a device driver’s DriverEntry function looks like this (decompiled in Ghidra, comments added manually): (code **)(param_1 + 0x70) = FUN_00011a08; // IRP_MJ_CREATE dispatch routine *(code **)(param_1 + 0x80) = FUN_00011a08; // IRP_MJ_CLOSE dispatch routine *(code **)(param_1 + 0xe0) = FUN_00010614; // IRP_MJ_DEVICE_CONTROL dispatch routine *(code **)(param_1 + 0xe8) = FUN_000104ac; // IRP_MJ_INTERNAL_DEVICE_CONTROL *(code **)(param_1 + 0x148) = FUN_00011c70; // IRP_MJ_PNP dispatch routine *(code **)(param_1 + 0x120) = FUN_00011bc8; // IRP_MJ_POWER dispatch routine *(code **)((longlong *)(param_1 + 0x30) + 8) = FUN_00011ad4; // AddDevice *(code **)(param_1 + 0x68) = FUN_00011b8c; // DriverUnload So, AddDevice is defined in FUN_00011ad4 and upon driver load (DriverEntry execution) its pointer is written into DriverObject->DriverExtension->AddDevice, just as all dispatch routine pointers are written into their relevant offsets.

But none of those functions have been invoked yet. For example, FUN_00010614 (IRP_MJ_DEVICE_CONTROL) will only execute once the driver receives an IRP with MajorFunction code = IRP_MJ_DEVICE_CONTROL (e.g. , in response to DeviceIoControl call from userland). Likewise, AddDevice is not called by the driver itself, but rather by the PnP manager under specific circumstances.

Now, let’s look into FUN_00011ad4 and see how a typical AddDevice implementation looks like: undefined8 FUN_00011ad4(undefined8 param_1,undefined8 param_2) { longlong lVar1; longlong lVar2; undefined8 uVar3; undefined8 uVar4; undefined8 uVar5; undefined8 uVar6; longlong local_res18 [2];

local_res18[0] = 0; lVar1 = (longlong *)(DAT_00011880 + 0x40); uVar3 = IoCreateDevice(param_1,0x100,0,0x22,0,0,local_res18); if (-1 < (int)uVar3) { lVar2 = *(longlong *)(local_res18[0] + 0x40); *(undefined1 *)(lVar2 + 5) = 0; *(undefined1 *)(lVar2 + 4) = 0; *(undefined8 *)(lVar2 + 0x18) = 0; *(undefined8 *)(lVar2 + 0x10) = param_2; *(longlong *)(lVar2 + 8) = local_res18[0]; *(undefined4 *)(lVar2 + 0x20) = 0x10000004; ExInterlockedInsertHeadList(lVar1,lVar2 + 0x28,lVar1 + 0x18); LOCK(); *(int *)(lVar1 + 0x10) = *(int *)(lVar1 + 0x10) + 1; UNLOCK(); KeInitializeEvent(lVar2 + 0x50,1); *(undefined4 *)(lVar2 + 0x68) = 1; *(uint *)(local_res18[0] + 0x30) = *(uint *)(local_res18[0] + 0x30) & 0xffffff7f; uVar3 = IoAttachDeviceToDeviceStack(local_res18[0],param_2); *(undefined8 *)(lVar2 + 0x18) = uVar3; uVar3 = 0; local_res18[0] = 0; RtlInitUnicodeString(&DAT_00011870,u_\Device\SampleDrv_00012270); uVar4 = IoCreateDevice(param_1,0x40,&DAT_00011870,0x22,0,0,local_res18); if (-1 < (int)uVar2) { RtlInitUnicodeString(&DAT_00011860,u_\DosDevices\SampleDrv_000122a0); uVar5 = IoCreateSymbolicLink(&DAT_00011860,&DAT_00011870); uVar6 = (ulonglong)uVar5; if ((int)uVar5 < 0) { IoDeleteDevice((undefined8 *)(param_1 + 8)); } } } return uVar3; } As we can see, two separate device objects are created. First, we have the following call to IoCreateDevice, whose returned value is saved in uVar3: uVar3 = IoCreateDevice(param_1,0x100,0,0x22,0,0,local_res18); The first param - param_1 - is a pointer to the driver object. The second parameter is the requested device extension size (0x100) for the newly created device. As the MSDN page says: > The device extension is the most important data structure associated with a device object .

Its internal structure is driver-defined , and it’s typically used to: > > Maintain device state information. > Provide storage for any kernel-defined objects or other system resources, such as spin locks, used by the driver. > Hold any data the driver must have resident and in system space to carry out its I/O operations. Device extension ( individual for every device object ) is not the same thing as driver extension (offset 0x30 in the DRIVER_OBJECT) mentioned earlier (where AddDevice pointer, if present, is stored at offset 0x8).

I am emphasizing the difference, because both terms sound similar, which may create confusion. We will get back to the most common application of the device extension structure later in this section. The third parameter is the device name - in this case, empty (unnamed device object), which is typical for FDOs. Looking further, after FDO creation, we have a whole block of code, which only executes if device object creation was successful: if (-1 < (int)uVar3)) { Several instructions further in that block, we have a call to IoAttachDeviceToStack : uVar3 = IoAttachDeviceToDeviceStack(local_res18[0],param_2); In AddDevice callback param_2 holds a pointer to the PDO created by the relevant bus driver .

Since AddDevice is invoked by the PnP manager, both parameters - param_1 pointing at the DRIVER_OBJECT and param_2 pointing at the PDO (DEVICE_OBJECT) - are provided by the PnP manager. So, at this point, we can clearly see that only if AddDevice is invoked will the driver create its FDO (and attach it to a device stack, making it accessible for IRP processing via handles opened on the PDO). Most PnP drivers only create one device object (FDO) in their AddDevice, and attach that object to a device stack, on top of the PDO pointed by param_2. This particular driver, however, also creates a CDO: Var4 = IoCreateDevice(param_1,0x40,&DAT_00011870,0x22,0,0,local_res18); Note that the third parameter is not 0 (which means a device name is provided).

And there is no IoAttachDeviceToStack call on that device object. So the device object is named and standalone - typical CDO. Both device objects are IRP entry points, and this driver will only create them when AddDevice is called. This structure applies to all FDOs and filter DOs.

In this particular driver we also have a CDO created in the AddDevice callback. Additionally, AddDevice is where drivers initialize their custom internal structures, including the ones located in device extension structures. If we look back into the AddDevice function above, we have such an example right in the beginning of the conditional code block, starting with this line: lVar2 = *(longlong *)(local_res18[0] + 0x40); local_res18[0] holds a pointer to the device object created by the preceding IoCreateDevice call. In a DEVICE_OBJECT, 0x40 is the offset of the device extension structure.

So lVar2 points at the device extension. Then, the next 7 instructions perform various initializations at arbitrary offsets of the device extension structure: *(undefined1 *)(lVar2 + 5) = 0; *(undefined1 *)(lVar2 + 4) = 0; *(undefined8 *)(lVar2 + 0x18) = 0; *(undefined8 *)(lVar2 + 0x10) = param_2; *(longlong *)(lVar2 + 8) = local_res18[0]; *(undefined4 *)(lVar2 + 0x20) = 0x10000004; ExInterlockedInsertHeadList(lVar1, lVar2 + 0x28, lVar1 + 0x18); The contents of the device extension structure is how WDM drivers usually recognize (make distinction) between device objects used to deliver the current IRP. It makes sense - after all, the device extension is a structure inside the device object, not the driver object. So upon device object creation the driver may put different values into individual device extension fields, so later when a pointer to that device is received in param_1 by a dispatch routine, the routine can read those values and use them in if conditions.

Oftentimes, vulnerable code in dispatch routines sits behind such conditional blocks, making vulnerable execution paths depend on the specific device object used to deliver the IRP. Now it becomes clear why having AddDevice called is crucial : It is required for the driver to initialize properly, which is oftentimes required for vulnerable code to become reachable from userland. This includes both: Otherwise-inaccessible conditional code branches. CDO creation (device object serving as entry point to the driver).

More importantly, the purpose of AddDevice is to create a new PnP-compatible (unnamed FDO/FiDO) device object and attach it to the device stack on top of the PDO provided by the PnPManager in the second argument ([in] _DEVICE_OBJECT *PhysicalDeviceObject). Which means that AddDevice is the function that connects the driver (via its FDO/FiDO) to a newly created device stack, allowing IRP travel. For each driver, multiple independent interaction (attack) vectors may exist . Their activation depends on proper driver initialization and typically materializes in one of the following forms: CDOs created from within the AddDevice routine.

Most PnP-compatible drivers do not create CDOs, but some do. FDOs and FiDOs created within AddDevice and attached on top of a newly created device stack. These devices can only be accessed via the stack. 3.3.2 IRP_MJ_PNP IRP_MJ_PNP is a MajorFunction IRP code dedicated for PnP-related interactions.

Each PnP-compatible driver must handle this code with a dedicated dispatch routine, often referred to as DispatchPnP . As the above MSDN page reads: > Associated with the IRP_MJ_PNP function code are several minor I/O function codes (see Plug and Play Minor IRPs ), some of which all drivers must handle and some of which can be optionally handled. The PnP manager uses these minor function codes to direct drivers to start, stop, and remove devices and to query drivers about their devices. While these routines are not as critical as AddDevice, because they are not responsible for the creation of the PnP-type device object, they usually implement other usual steps of driver initialization logic, such as: - initialization of global driver-internal variables, - configuration file checks, - device interface registration, - hardware probing and validation.

It is worth keeping in mind that there is a difference in how WDM and WDF drivers structure those callbacks in their code. WDM drivers set a traditional IRP_MJ_PNP dispatch routine on the DriverObject->MajorFunction table. Any processing of PnP minor IRPs is handled in that routine. WDF (KMDF) drivers register PnP/power state-change callbacks via WdfDeviceInitSetPnpPowerEventCallbacks , which provides clear separation of functions dedicated for handling individual minor IRPs.

These differences become relevant during static analysis and debugging, but they do not affect they way drivers are set up from userland to get those routines properly invoked. 3.4 Active hardware interaction and probing Only a small fraction of driver code actually interacts with physical hardware. The relevant direct and indirect interaction mechanisms include: - legacy x86 port I/O (https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/nf-wdm-read_port_uchar, https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/nf-wdm-write_port_uchar and related IN/OUT instruction wrappers), - Memory-Mapped I/O (https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/nf-wdm-mmmapiospace, https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/nf-wdm-read_register_ulong and variants), - PCI configuration space (https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntddk/nf-ntddk-halgetbusdatabyoffset), - ACPI control methods (https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/acpiioct/ni-acpiioct-ioctl_acpi_eval_method), - Serial Peripheral Bus (https://learn.microsoft.com/en-us/windows-hardware/drivers/spb/spb-ioctls and related SPB I/O requests), - GPIO (https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/gpio/ni-gpio-ioctl_gpio_read_pins), - DMA (https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/nf-wdm-iogetdmaadapter), - interrupts (https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/nf-wdm-ioconnectinterruptex), - calls to other drivers via https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/nf-wdm-iofcalldriver. When considering hardware-gated code and by extension hardware-gated vulnerabilities, it is crucial to understand the context.

To illustrate this, let’s consider three different examples, all involving the same mechanism - MMIO . 3.4.1 Neutral hardware use Fixed address 0xFEE00000, universally present: // Local APIC — fixed at 0xFEE00000 on all x86 systems base = MmMapIoSpace(0xFEE00000, PAGE_SIZE, MmNonCached); version = READ_REGISTER_ULONG(base + 0x30); MmUnmapIoSpace(base, PAGE_SIZE); No hardware-gating, no security impact. 3.4.2 Vulnerable hardware use In this scenario, we have an arbitrary physical memory write (vulnerable use of MmMapIoSpace, followed by WRITE_REGISTER_ULONG). It is unconditionally reachable - any system running the driver is exposed: // Physical address and offset supplied by usermode via IOCTL base = MmMapIoSpace(input->PhysicalAddress, input->Size, MmNonCached); WRITE_REGISTER_ULONG(base + input->Offset, input->Value); MmUnmapIoSpace(base, input->Size); 3.4.3 Hardware gating And here we also have an arbitrary physical memory write, but an attacker can only reach it on machines where the hardware chip ID check passes.

That’s the hardware gate: the MmMapIoSpace on a non-existent BAR returns NULL or maps to nothing meaningful, and chipId won’t match: // BAR address obtained from PCI config space of a specific device base = MmMapIoSpace(barAddress, BAR_SIZE, MmNonCached); chipId = READ_REGISTER_ULONG(base + CHIP_ID_REGISTER);

if (chipId == 0x1234ABCD) { WRITE_REGISTER_ULONG(base + input->Offset, input->Value); } MmUnmapIoSpace(base, BAR_SIZE); For more such latest threat research and vulnerability advisory, please subscribe to Atos Cyber Shield blogs. 4 How driver deployment can be approached from the BYOVD perspective In this section we are going to try to evaluate how much influence over proper driver initialization is possible by solely operating from userland (with administrative privileges), to reflect a typical BYOVD scenario. So in this section we are not considering techniques involving: - physical access, - hypervisor level access allowing creation of virtualized hardware, - non-standard/insecure system configurations, such as disabled driver signature enforcement, - artificial alterations of execution flow using kernel mode debugger, or any other use of kernel mode debugger. While the above techniques are all interesting and valuable for security research and testing, they are out of scope of this article.

4.1 Simple sc.exe deployment This is the simplest, minimal step required to trigger driver load. We create a relevant service entry, then we trigger driver load by starting that service: sc create SampleDrv type= kernel start= demand binPath= System32\drivers\SampleDrv.sys && sc.exe start Note, this deployment alone makes the driver execute its DriverEntry, but does not cover any PnP setup. In terms of named device creation, this setup approach is sufficient for drivers matching the pattern described in 3.1 Unconditional creation upon driver load . Now, if we want to test if the driver created any named device objects, the easiest way not involving WinDBG usage is to: Use NtObjectManager to list the \Devices directory and save that list.

Deploy and start the driver (sc create + sc start). Use NtObjectManager again to list the \Devices directory and compare the result with the list obtained in step 1. If a new device object was detected, try obtaining its SDDL. Successful reading of SDDL proves it is possible to open a handle from userland, and only these devices are reported.

A Powershell implementation can be found here . Let’s see this script in action. First, this is what we can expect to see for a driver that loads, but does not create any new devices: PS C:\test> .\sc_deploy_detect.ps1 C:\runtime_service\IFM63X64.sys Returning device list (193 elements). [SC] CreateService SUCCESS

SERVICE_NAME: IFM63X64 TYPE : 1 KERNEL_DRIVER STATE : 4 RUNNING (STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN) WIN32_EXIT_CODE : 0 (0x0) SERVICE_EXIT_CODE : 0 (0x0) CHECKPOINT : 0x0 WAIT_HINT : 0x0 PID : 0 FLAGS : Returning device list (193 elements).

We can see that the driver was successfully loaded, but the device list did not change after that. Now, here is an example of a driver that does create a new device right away upon load: PS C:\test> .\sc_deploy_detect.ps1 C:\runtime_service\KfeCo11x64.sys Returning device list (193 elements). [SC] CreateService SUCCESS

SERVICE_NAME: KfeCo11x64 TYPE : 1 KERNEL_DRIVER STATE : 4 RUNNING (STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN) WIN32_EXIT_CODE : 0 (0x0) SERVICE_EXIT_CODE : 0 (0x0) CHECKPOINT : 0x0 WAIT_HINT : 0x0 PID : 0 FLAGS : Returning device list (194 elements). New device found for \Device\KfeCoDriver (symlink: ) O:BAG:SYD:P(A;;FA;;;SY)(A;;FA;;;BA) This deployment and device detection approach is fast and practical for runtime discovery of drivers that create userland-accessible CDOs out of the box.

However, it is not sufficient for PnP device objects, which are far more common and thus constitute a much larger attack surface. Also, keep in mind that many drivers deployed this way will fail to load due to missing dependencies. Those are usually satisfied when the deployment is conducted using the original installer and INF file . 4.2 Creating software-emulated devices with spoofed hardware ID 4.2.1 The idea After digging a bit and learning more about the driver deployment process, I stumbled upon the test device functionality provided by devcon.exe , which provides the ability to create device nodes with arbitrary (spoofed) hardware IDs.

So it became clear to me that these devices could be used to compensate for the missing hardware and get the AddDevice callback invoked. Most device drivers come with INF files, which tie drivers to physical hardware by hardware IDs . The easiest way to identify hardware ID (or IDs) matching a driver is by viewing its INF file. Hardware IDs are located in the Models sections, for example: Here is a Python implementation extracting hardware IDs from INF files.

[SampleDrv.NTamd64]

%SampleDrv.DeviceDesc% = SampleDrv,ACPI\SAMPLEDRV7853 Once we have a matching hardware ID, instead of explicitly calling sc.exe, we deploy the driver as follows: pnputil.exe /add-driver SampleDrv.inf /install devcon.exe install SampleDrv.inf “ACPI\SAMPLEDRV7853” First, we use pnputil to deploy the driver package into the Windows Driver Store. Next, we use devcon to create a new software-emulated device node with an arbitrary hardware ID that matches one defined in the driver’s INF file. This action triggers the PnP manager to detect the newly staged driver as the best match for the device. As a result, the driver’s AddDevice routine gets executed.

While pnputil.exe is present on every Windows system, devcon.exe is not, but it can be found in WDK . The algorithm of detecting new named device objects as a result of this deployment approach is the same, except for the deployment commands. The devcon version of the deploy and detect PowerShell script can be found here . The output generated by this script looks the same as for the sc.exe version.

4.2.2 Initial test results My preliminary experiments with this deployment approach resulted in almost twice as many new device objects created as compared to the simple sc.exe create, non-PnP deployment. This clearly demonstrates that software-emulated device nodes with spoofed hardware IDs are a viable userland-only method of making (some) drivers reachable without their relevant hardware. I was able to find and confirm numerous driver vulnerabilities this way, including very good BYOVD candidates. It is important to note that the algorithm used to detect new named device objects includes both CDOs as well as FDOs attached on top of the software-emulated PDO with an auto-generated name.

In the screenshot below, demonstrating a fragment of the aggregated result log, we can see one CDO and one PDO (with auto-generated name) created by the same driver, both with readable security descriptors: New named devices created during devcon install For visibility, the log file also includes newly discovered device objects whose SDDLs could not be obtained. Those make up the majority. And here we can see 3 PDOs with auto-generated names, whose security descriptors are readable (the additional column is the GLOBAL?? symlink name, in this case automatically created with device interface registration): New named devices created during devcon install So, an obvious question arises: Why were the security descriptors of so many device objects created during this test not readable?

And secondly, what are we really doing when running “devcon.exe install path_to.inf HWID”? To answer these questions, let’s have a closer look at the process of software-emulated device creation. 4.2.3 Creating software-emulated devices with SoftwareDevice and PnpManager Keep in mind that creating a software-emulated device and telling Windows to use a specific driver to drive that device are two separate steps: 1. First, we create a software-emulated device with a spoofed hardware ID.

1. Then we invoke the driver installation/update process for that device using the original INF file ( UpdateDriverForPlugAndPlayDevicesW ), to eventually run the driver on the emulated device. When it comes to the first step, the Windows kernel itself provides two similar mechanisms allowing creation of software-emulated devices with arbitrary hardware IDs: The first method is provided by the PnPManager driver itself, and it can be performed by using Config Manager API/SetupAPI . This is how devcon.exe implements its software-emulated device creation.

The second one is provided by the SoftwareDevice driver, using Software Device API . Both drivers are embedded in ntoskrnl.exe. In both cases we are creating PnP device nodes with arbitrary hardware IDs. Let’s have a closer look into this process.

4.2.3.1 SetupAPI and PnpManager - process overview Setting up a software-emulated device using SetupAPI requires the following sequence of API calls: SetupDiCreateDeviceInfoList

• create an empty device info set for our class. SetupDiCreateDeviceInfoW
• create device node. SetupDiSetDeviceRegistryPropertyW
• set the hardware ID on the devnode. SetupDiCallClasInstaller
• register the device with PnP.

UpdateDriverForPlugAndPlayDevicesW

• force driver update for provided HWID, using provided INF file. Calling SetupDiCallClassInstaller (step 4) triggers a sequence of operations on the kernel level, including a call to IoCreateDevice (PnpManager creating the new device object). UpdateDriverForPlugAndPlayDevicesW requests the PnP manager to install a driver for that device. Before that happens, the device will show DOE_START_PENDING in its extension flags, when inspected with !devobj in WinDBG: 0: kd> !devobj \Device\0000003b …

ExtensionFlags (0x00000810) DOE_START_PENDING, DOE_DEFAULT_SD_PRESENT … Once the driver is bound to the device, the target driver’s AddDevice will be invoked by PnpManager, passing a pointer to the PDO (owned by PnpManager) as the second argument. AddDevice is expected to create its FDO and attach it on top of the PDO using IoAttachDeviceToDeviceStack. 4.2.3.2 SetupAPI and PnpManager - device node creation only Let’s use the following C implementation of steps 1-4, to only create a new device node with an arbitrary hardware ID, then inspect the device node in Device Manager and inspect its named device object in WinDBG.

This way we can skip using an INF file entirely (for now) and examine the newly created named device object in its default state, without the PnP manager making any attempts to build a device stack on top of it. create_swdev_cm.exe FAKEHW_ID Device node created successfully for hardware ID: FAKEHW_ID We should be able to see the new device node (as “Unknown”) in Software Devices in the Device Manager view. We can manually select and view different device node properties, such as device instance path, hardware ID and even PDO name: Device manager view - instance path Device manager view - hardware ID Device manager view - Physical Device Object name Let’s inspect the PDO name in WinDBG: 0: kd> !devobj \Device\00000036 Device object (ffff8207ddc03300) is for: 00000036 \Driver\PnpManager DriverObject ffff8207d8aa3290 Current Irp 00000000 RefCount 0 Type 00000004 Flags 00001040 SecurityDescriptor ffffd408ceb1d260 DevExt ffff8207ddc03450 DevObjExt ffff8207ddc03458 DevNode ffff8207deca0660 ExtensionFlags (0x00000800) DOE_DEFAULT_SD_PRESENT Characteristics (0x00000080) FILE_AUTOGENERATED_DEVICE_NAME Device queue is not busy. We can see that the driver owning the device object is \Driver\PnpManager, the device object has an auto-generated name and a default (permissive) security descriptor.

Also note that the device object is NOT attached to any device stack here (there is no AttachedDevice etc.), so we can rule out a filter blocking access to it from above. Examining the security descriptor in WinDBG confirms the default, permissive security descriptor: 0: kd> !sd ffffd408ceb1d260 ->Revision: 0x1 ->Sbz1 : 0x0 ->Control : 0x8814 SE_DACL_PRESENT SE_SACL_PRESENT SE_SACL_AUTO_INHERITED SE_SELF_RELATIVE ->Owner : S-1-5-32-544 ->Group : S-1-5-21-557163823-2925933541-2346282345-513 ->Dacl : ->Dacl : ->AclRevision: 0x2 ->Dacl : ->Sbz1 : 0x0 ->Dacl : ->AclSize : 0x5c ->Dacl : ->AceCount : 0x4 ->Dacl : ->Sbz2 : 0x0 ->Dacl : ->Ace[0]: ->AceType: ACCESS_ALLOWED_ACE_TYPE ->Dacl : ->Ace[0]: ->AceFlags: 0x0 ->Dacl : ->Ace[0]: ->AceSize: 0x14 ->Dacl : ->Ace[0]: ->Mask : 0x001201bf ->Dacl : ->Ace[0]: ->SID: S-1-1-0

->Dacl : ->Ace[1]: ->AceType: ACCESS_ALLOWED_ACE_TYPE ->Dacl : ->Ace[1]: ->AceFlags: 0x0 ->Dacl : ->Ace[1]: ->AceSize: 0x14 ->Dacl : ->Ace[1]: ->Mask : 0x001f01ff ->Dacl : ->Ace[1]: ->SID: S-1-5-18

->Dacl : ->Ace[2]: ->AceType: ACCESS_ALLOWED_ACE_TYPE ->Dacl : ->Ace[2]: ->AceFlags: 0x0 ->Dacl : ->Ace[2]: ->AceSize: 0x18 ->Dacl : ->Ace[2]: ->Mask : 0x001f01ff ->Dacl : ->Ace[2]: ->SID: S-1-5-32-544

->Dacl : ->Ace[3]: ->AceType: ACCESS_ALLOWED_ACE_TYPE ->Dacl : ->Ace[3]: ->AceFlags: 0x0 ->Dacl : ->Ace[3]: ->AceSize: 0x14 ->Dacl : ->Ace[3]: ->Mask : 0x001200a9 ->Dacl : ->Ace[3]: ->SID: S-1-5-12

->Sacl : ->Sacl : ->AclRevision: 0x2 ->Sacl : ->Sbz1 : 0x0 ->Sacl : ->AclSize : 0x1c ->Sacl : ->AceCount : 0x1 ->Sacl : ->Sbz2 : 0x0 ->Sacl : ->Ace[0]: ->AceType: SYSTEM_MANDATORY_LABEL_ACE_TYPE ->Sacl : ->Ace[0]: ->AceFlags: 0x0 ->Sacl : ->Ace[0]: ->AceSize: 0x14 ->Sacl : ->Ace[0]: ->Mask : 0x00000001 ->Sacl : ->Ace[0]: ->SID: S-1-16-4096 But when we try to display the security descriptor with NtObjectManager, we will encounter the following error message: Failure attempting to read SDDL of unattached PDO The requested operation is not valid for the target device? In the introduction article , in section 3.6.7 Filters as access control , I demonstrated a similar situation, only with Access denied . In that case the upper driver in the stack was blocking IRP_MJ_CREATE, so the IRP never even reached the named PDO down the stack (the one used to open the handle).

Since here we only have one device object instead of a device stack, it must be PnpManager itself blocking those requests. Let’s have a look at its dispatch routine table: 0: kd> !drvobj PnpManager 2 Driver object (ffff8207d8aa3290) is for: \Driver\PnpManager … Dispatch routines: [00] IRP_MJ_CREATE fffff8053ff516b0 nt!IopInvalidDeviceRequest [01] IRP_MJ_CREATE_NAMED_PIPE fffff8053ff516b0 nt!IopInvalidDeviceRequest [02] IRP_MJ_CLOSE fffff8053ff516b0 nt!IopInvalidDeviceRequest [03] IRP_MJ_READ fffff8053ff516b0 nt!IopInvalidDeviceRequest [04] IRP_MJ_WRITE fffff8053ff516b0 nt!IopInvalidDeviceRequest [05] IRP_MJ_QUERY_INFORMATION fffff8053ff516b0 nt!IopInvalidDeviceRequest [06] IRP_MJ_SET_INFORMATION fffff8053ff516b0 nt!IopInvalidDeviceRequest [07] IRP_MJ_QUERY_EA fffff8053ff516b0 nt!IopInvalidDeviceRequest [08] IRP_MJ_SET_EA fffff8053ff516b0 nt!IopInvalidDeviceRequest [09] IRP_MJ_FLUSH_BUFFERS fffff8053ff516b0 nt!IopInvalidDeviceRequest [0a] IRP_MJ_QUERY_VOLUME_INFORMATION fffff8053ff516b0 nt!IopInvalidDeviceRequest [0b] IRP_MJ_SET_VOLUME_INFORMATION fffff8053ff516b0 nt!IopInvalidDeviceRequest [0c] IRP_MJ_DIRECTORY_CONTROL fffff8053ff516b0 nt!IopInvalidDeviceRequest [0d] IRP_MJ_FILE_SYSTEM_CONTROL fffff8053ff516b0 nt!IopInvalidDeviceRequest [0e] IRP_MJ_DEVICE_CONTROL fffff8053ff516b0 nt!IopInvalidDeviceRequest [0f] IRP_MJ_INTERNAL_DEVICE_CONTROL fffff8053ff516b0 nt!IopInvalidDeviceRequest [10] IRP_MJ_SHUTDOWN fffff8053ff516b0 nt!IopInvalidDeviceRequest [11] IRP_MJ_LOCK_CONTROL fffff8053ff516b0 nt!IopInvalidDeviceRequest [12] IRP_MJ_CLEANUP fffff8053ff516b0 nt!IopInvalidDeviceRequest [13] IRP_MJ_CREATE_MAILSLOT fffff8053ff516b0 nt!IopInvalidDeviceRequest [14] IRP_MJ_QUERY_SECURITY fffff8053ff516b0 nt!IopInvalidDeviceRequest [15] IRP_MJ_SET_SECURITY fffff8053ff516b0 nt!IopInvalidDeviceRequest [16] IRP_MJ_POWER fffff8054015fa10 nt!IopPowerDispatch [17] IRP_MJ_SYSTEM_CONTROL fffff80540561f30 nt!IopSystemControlDispatch [18] IRP_MJ_DEVICE_CHANGE fffff8053ff516b0 nt!IopInvalidDeviceRequest [19] IRP_MJ_QUERY_QUOTA fffff8053ff516b0 nt!IopInvalidDeviceRequest [1a] IRP_MJ_SET_QUOTA fffff8053ff516b0 nt!IopInvalidDeviceRequest [1b] IRP_MJ_PNP fffff805402c6940 nt!IopPnPDispatch Aha! The dispatch routine values for most MajorFunction codes are set to nt!IopInvalidDeviceRequest.

Which means that the driver simply does not support them. Without IRP_MJ_CREATE we cannot open a handle, even to read the security descriptor. In the case described in the introduction article (section 3.6.7 Filters as access control ), the upper driver called IofCompleteRequest, with Irp->IoStatus.Status = STATUS_ACCESS_DENIED. In this case, IRP_MJ_CREATE returns Irp->IoStatus.Status = STATUS_INVALID_DEVICE_REQUEST.

The reason this is happening is because the driver owning the PDO is simply not intended to be responsible for handling IRP_MJ_CREATE requests. In typical device stacks, the handling of IRP_MJ_CREATE should take place in the FDO and end there (with IofCompleteRequest), with IRP_MJ_CREATE never being passed down the stack. Which leads us to an important conclusion - if we are trying to open a handle to a device stack, at least one device in that stack must successfully handle our IRP_MJ_CREATE. We cannot open a handle to a device stack if neither of the following accepts IRP_MJ_CREATE: Upper FiDO (if present).

FDO. Lower FiDO (if present). The PDO (if IRP ever reaches here). PDO is always the base of a device stack, so it’s always present.

This is why we cannot open a handle to a bare (non-stack-attached) named PDO created by PnpManager. A large portion of the failed deployment attempts observed in the aggegated log - where no security descriptors could be obtained for the newly created devices - was caused by the lack of IRP_MJ_CREATE support in the PnP Manager, combined with the absence of an upper-level driver in the device stack to handle that IRP. Which is what happened when: - UpdateDriverForPlugAndPlayDevicesW succeeded, but the target driver did not support IRP_MJ_CREATE either, - UpdateDriverForPlugAndPlayDevicesW failed for any reason (.cat file missing, other dependancy referred in the INF file missing, or even the driver not loading). 4.2.3.3 SetupAPI and PnpManager - complete and successful deployment Now, for contrast, let’s see how a full (steps 1-5) and successful deployment looks like, using the Powershell script .

We will use AwinicSmartKAmps.sys (I2C smart amplifier controller) driver as an example. First, let’s have a look at its INF file. On line 32 we can find the hardware ID - ACPI\AWDZ8399. It is also worth noting that on line 50 the “AddService” directive defines the driver’s service name as AwinicChip.

This is how the driver object will be named, even though the .sys file itself is named AwinicSmartKAmps.sys (as visible on line 58): Hardware ID from INF file We run the deployment script: Hardware ID from INF file Interesting - two new named device objects were detected, and they are both userland-accessible (SDDLs could be retrieved)! Let’s inspect the driver object in WinDBG: !drvobj AwinicChip 7 Driver object (ffffe18f33ff3e10) is for: \Driver\AwinicChip

Driver Extension List: (id , addr) (fffff805394622e0 ffffe18f2ec1a950) Device Object list: ffffe18f32ce6de0

DriverEntry: fffff80562ba0630 AwinicSmartKAmps DriverStartIo: 00000000 DriverUnload: fffff80562ba07c0 AwinicSmartKAmps AddDevice: fffff80539462090

Dispatch routines: [00] IRP_MJ_CREATE fffff80539427ac0 +0xfffff80539427ac0 … Device Object stacks:

!devstack ffffe18f32ce6de0 : !DevObj !DrvObj !DevExt ObjectName ffffe18f34e51e00 \Driver\ksthunk ffffe18f34e51f50 0000002e

ffffe18f32ce6de0 \Driver\AwinicChip ffffe18f35cde310 ffffe18f35b0db90 \Driver\PnpManager ffffe18f35b0dce0 0000002d !DevNode ffffe18f32f32b20 : DeviceInst is “ROOT\MEDIA\0000” ServiceName is “AwinicChip” We can see that our driver created one device object (ffffe18f32ce6de0), which was then attached into a device stack on top of \Device\0000002d (software-emulated PDO created by PnpManager), and additionally to that, the PnP manager also attached another (also named) device object on top of it - \Device\0000002e (owned by \Driver\ksthunk). If we look at the beginning of the INF file, we’ll notice this: Hardware ID from INF file The driver class is defined as Multimedia, using the well-known {4d36e96c-e325-11ce-bfc1-08002be10318} GUID .

ksthunk (Kernel Streaming) is registered as a class upper filter for the MEDIA device setup class. This can be confirmed by inspecting the UpperFilters REG_MULTI_SZ registry entry at HKLM\SYSTEM\CurrentControlSet\Control\Class{4d36e96c-e325-11ce-bfc1-08002be10318}: Hardware ID from INF file The PnP manager automatically attaches class upper filter device objects to every device in the class it is set up for. That’s why \Device\0000002e owned by \Driver\ksthunk is present in the device stack on top of our driver’s unnamed FDO. We will revisit the UpperFilters mechanism later in this article.

Another consequence of the driver being installed as a Media device is how its device node is visible in the Device Manager GUI tool. It appears in the “Sound, video and game controllers” subtree: Hardware ID from INF file Hardware ID from INF file Before we move on, while we already have the driver loaded, let’s set up a couple of breakpoints: 0: kd> bp fffff80539462090 “.echo AddDevice called;g” 0: kd> bp fffff80539427ac0 “.echo IRP_MJ_CREATE called;g” 0: kd> g We already know these addresses from the output of !drvobj AwinicChip 7. Now, IRP_MJ_CREATE should hit whenever we attempt to open a handle to any device in the stack: Invoking IRP_MJ_CREATE In the debugger output we should see: IRP_MJ_CREATE called IRP_MJ_CREATE called And if we manually invoke the creation of another device node using the same hardware ID (by simply running devcon.exe install AwinicSmartKAmps.inf “ACPI\AWDZ8399” again), we should see the AddDevice breakpoint hitting as well: AddDevice called Keep in mind that AddDevice being invoked only means that we have managed to trick the PnP manager to call it. It does not neccessarily mean that AddDevice will successfully create a new device object and attach it to the the device stack - it may still fail internally due to additional unmet conditions.

From the practical perspective, the easiest way to confirm the success of this type of deployment, is reading the security descriptor of the software-emulated device. If that works, it means that: - driver installation (UpdateDriverForPlugAndPlayDevicesW call) was successful, - in the newly created device stack there is a driver that accepts IRP_MJ_CREATE. Here is the full version the setup program (steps 1-5). Requires INF file.

4.2.3.4 Software Device API An alternative to the SetupAPI device creation approach is Software Device API . Creation of a software-emulated device with arbitrary hardware ID is simpler than with SetupAPI, as it boils down to just calling SwDeviceCreate . A sample C implementation can be found here . It can be easily extended with UpdateDriverForPlugAndPlayDevicesW (requires INF file).

By default the device object gets removed when we close the HSWDEVICE hSwDevice handle (the handle populated by SwDeviceCreate). To prevent that, before closing the handle, the program calls hr = SwDeviceSetLifetime(hSwDevice, SWDeviceLifetimeParentPresent);. Device objects created this way are owned by \Driver\SoftwareDevice (as a reminder, the ones created with SetupAPI are owned by \Driver\PnpManager). Hardware ID spoofed with SoftwareDevice API Hardware ID spoofed with SoftwareDevice API A quick inspection of the device object is WinDBG: 0: kd> !devobj \Device\00000036 0: kd> Device object (ffffaa0a87a6de00) is for: 00000036 \Driver\SoftwareDevice DriverObject ffffaa0a8273ce00 Current Irp 00000000 RefCount 0 Type 00000022 Flags 00001040 SecurityDescriptor ffffce8086380820 DevExt ffffaa0a87a6df50 DevObjExt ffffaa0a87a6df60 DevNode ffffaa0a86a1a8e0 ExtensionFlags (0x00000800) DOE_DEFAULT_SD_PRESENT Characteristics (0x00000180) FILE_AUTOGENERATED_DEVICE_NAME, FILE_DEVICE_SECURE_OPEN AttachedDevice (Upper) ffffaa0a88033de0 \Driver\AwinicChip Device queue is not busy.

And just like \Driver\PnpManager, the \Driver\SoftwareDevice driver does not support IRP_MJ_CREATE: 0: kd> !drvobj SoftwareDevice 2

Driver object (ffffaa0a8273ce00) is for: \Driver\SoftwareDevice

DriverEntry: fffff8074ad32f40 nt!PiSwPdoDriverEntry DriverStartIo: 00000000 DriverUnload: 00000000 AddDevice: fffff8074a9e4400 nt!ArbPreprocessEntry

Dispatch routines: [00] IRP_MJ_CREATE fffff8074a5516b0 nt!IopInvalidDeviceRequest 4.3 Jumping device stacks Making a PnP-compatible driver reachable with a software-emulated device is an example of building and accessing a custom device stack . That opens the way to even interact via IRP with drivers that were never intended for userland interaction (e.g. not checking IRP’s RequestorMode prior to further processing), because when deployed the original way they reside in device stacks where an upper driver prevents userland access (by denying or not supporting IRP_MJ_CREATE), just like in the example demonstrated in section 3.6.7 Filters as access control in the introduction article . So, if we find a vulnerability in a driver that cannot be interacted with from userland in its original configuration, that driver is not useful for Local Privilege Escalation.

But for breaking the admin to kernel boundary it might. We just need to deploy it in a way that allows exploitability, by placing it in a device stack where the original upper filter is not present. We could call this malicious driver misconfiguration/deployment. This approach is not only useful for testing, but also for making vulnerabilities reachable, and thus potentially exploitable during BYOVD attacks.

Let’s see another variant of this. 4.3.1 Filter restacking Once we understand that in order to access a device stack, one of its drivers must accept our IRP_MJ_CREATE, it becomes clear why the deployment scenario covered in section 4.3 could not succeed for filter drivers. A typical filter driver is a pass-through IRP forwarder, which means it does not reject IRP_MJ_CREATE, but it does not accept it either. It does have the relevant dispatch routine, and that routine usually just forwards IRPs down the stack.

So, if we try to access a filter driver by putting it on top of a software-emulated PDO, we won’t be able to open a handle. That is because neither of the two drivers supports IRP_MJ_CREATE. The filter driver forwards it down to the PDO, and the PDO rejects it via nt!IopInvalidDeviceRequest. This is why for filter drivers we need a device stack with a typical FDO below (or just any driver that will accept IRP_MJ_CREATE from userland).

One way to build such a device stack is by abusing the Disk Drive class (GUID {4d36e967-e325-11ce-bfc1-08002be10318}) . The algorithm is as follows: Deploy the filter driver with sc.exe create (no INF files involved) Append the filer’s service name to the UpperFilters registry key for the device Disk Drive device class in HKLM:\SYSTEM\CurrentControlSet\Control\Class{4d36e967-e325-11ce-bfc1-08002be10318}. Mount a new hard drive from VHD, creating a new device node and PnP building a new device stack for it. Filter becomes accessible once we open a handle on \.\PhysicalDrive0.

A PowerShell implementation can be found here . This deployment scenario works for most filter drivers, regardless of the device class the filter is intended for. This way I successfully ran (and in some cases exploited) filter drivers for various device clasess, such as disk, bluetooth, mouse, keyboard and audio. For instance, here we are loading a gaming mouse filter driver on top of a disk stack: Running a gaming mouse filter on top of disk stack If we inspect the driver object in WinDBG, we will see the entire device stack, including GMLXDFltr with its unnamed FiDO on top of it: 0: kd> !drvobj GMLXDFltr Driver object (ffffd20a9c4cde20) is for: \Driver\GMLXDFltr

Driver Extension List: (id , addr)

Device Object list: ffffd20a9b8a3690 ffffd20a9753b910 0: kd> !devobj ffffd20a9b8a3690 Device object (ffffd20a9b8a3690) is for: \Driver\GMLXDFltr DriverObject ffffd20a9c4cde20 Current Irp 00000000 RefCount 0 Type 00000022 Flags 00000000 SecurityDescriptor ffffe48d055db5a0 DevExt ffffd20a9b8a37e0 DevObjExt ffffd20a9b8a3868 ExtensionFlags (0000000000) Characteristics (0x00000100) FILE_DEVICE_SECURE_OPEN AttachedTo (Lower) ffffd20a9ba1f690 \Driver\partmgr Device queue is not busy.

0: kd> !devstack ffffd20a9b8a3690 !DevObj !DrvObj !DevExt ObjectName

ffffd20a9b8a3690 \Driver\GMLXDFltr ffffd20a9b8a37e0 ffffd20a9ba1f690 \Driver\partmgr ffffd20a9ba1f7e0 ffffd20a9f187060 \Driver\disk ffffd20a9f1871b0 DR1 ffffd20aa30e8050 \Driver\vhdmp ffffd20aa30e81a0 00000038 !DevNode ffffd20a9b8998c0 : DeviceInst is “SCSI\Disk&Ven_Msft&Prod_Virtual_Disk\2&1f4adffe&0&000001” ServiceName is “disk” Let’s set a breakpoint on its IRP_MJ_CREATE dispatch routine. First, obtain the address: 0: kd> !drvobj GMLXDFltr 2 Driver object (ffffd20a9c4cde20) is for: \Driver\GMLXDFltr

DriverEntry: fffff80085a52244 GMLXDFltr DriverStartIo: 00000000 DriverUnload: fffff80085a51b8c GMLXDFltr AddDevice: fffff80085a51ab4 GMLXDFltr Dispatch routines: [00] IRP_MJ_CREATE fffff80085a51a08 GMLXDFltr+0x1a08 Then set up a breakpoint, resume execution: 0: kd> bp GMLXDFltr+0x1a08 “.echo GMLXDFltr IRP_MJ_CREATE called;g” 0: kd> g On the VM, resolve the device path and trigger IRP_MJ_CREATE by attempting to read the SDDL: PS C:> Get-NtSymbolicLinkTarget ‘\GLOBAL??\PhysicalDrive1’ \Device\Harddisk1\DR1 PS C:> Get-NtSecurityDescriptor ‘\Device\Harddisk1\DR1’

Owner DACL ACE Count SACL ACE Count Integrity Level —– ————– ————– ————— BUILTIN\Administrators 5 NONE NONE Debugger output: 0: kd> g GMLXDFltr IRP_MJ_CREATE called GMLXDFltr IRP_MJ_CREATE called So, it is working! We are accessing a gaming mouse filter driver via a handle opened on \Device\Harddisk1\DR1 ! On a side note, surprisingly, the breakpoint is activated twice, not once.

Why? To find out, let’s start with confirming the identity of the userland process. For that we can attach the following script to run when the breakpoint hits, so it prints the image name of the current userland caller: bp GMLXDFltr+0x1a08 “.echo GMLXDFltr IRP_MJ_CREATE ran;.scriptrun C:\Users\ewilded\curr_image_name.js;g” breakpoint 0 redefined 0: kd> g And now, when Get-NtSecurityDescriptor ‘\Device\Harddisk1\DR1’ is invoked again, we get: GMLXDFltr IRP_MJ_CREATE ran JavaScript script successfully loaded from ‘C:\Users\ewilded\WinDBG_scripts\curr_image_name.js’ Current Process Image Name: powershell.exe GMLXDFltr IRP_MJ_CREATE ran JavaScript script successfully loaded from ‘C:\Users\ewilded\WinDBG_scripts\curr_image_name.js’ Current Process Image Name: powershell.exe So in both cases the caller is powershell. Let’s also print the DesiredAccess via IRP IO_STACK_LOCATION, to get more details: 1: kd> g GMLXDFltr IRP_MJ_CREATE ran Current Process Image Name: powershell.exe GMLXDFltr+0x1a08: fffff80085a51a08 48895c2408 mov qword ptr [rsp+8],rbx 2: kd> dt nt!_IRP @rdx Tail.Overlay.CurrentStackLocation +0x078 Tail : +0x000 Overlay : +0x040 CurrentStackLocation : 0xffffd20a9d4806f8 _IO_STACK_LOCATION 2: kd> dt nt!_IO_STACK_LOCATION 0xffffd20a9d4806f8 Parameters.Create.SecurityContext +0x008 Parameters : +0x000 Create : +0x000 SecurityContext : 0xfffff5040ab565d0 _IO_SECURITY_CONTEXT 2: kd> dt nt!_IO_SECURITY_CONTEXT 0xfffff504`0ab565d0 DesiredAccess +0x010 DesiredAccess : 0x20000 So during the first call of GMLXDFltr+0x1a08, the DesiredAccess is 0x20000.

Let’s resume execution and inspect the same property on the second breakpoint hit: 2: kd> g GMLXDFltr IRP_MJ_CREATE ran Current Process Image Name: powershell.exe GMLXDFltr+0x1a08: fffff80085a51a08 48895c2408 mov qword ptr [rsp+8],rbx 0: kd> dt nt!_IRP @rdx Tail.Overlay.CurrentStackLocation +0x078 Tail : +0x000 Overlay : +0x040 CurrentStackLocation : 0xffffd20a9dc4a808 _IO_STACK_LOCATION 0: kd> dt nt!_IO_STACK_LOCATION 0xffffd20a`9dc4a808 Parameters.Create.SecurityContext +0x008 Parameters : +0x000 Create : +0x000 SecurityContext : (null) So, in the first call, DesiredAccess is 0x20000. But in the second one, the SecurityContext is NULL. This strongly suggests that in this second call, we are not dealing with IRP_MJ_CREATE at all. Let’s examine the call stacks when the breakpoint hits.

First: GMLXDFltr+0x1a08: fffff80085a51a08 48895c2408 mov qword ptr [rsp+8],rbx 3: kd> k # Child-SP RetAddr Call Site 00 fffff5040ab56448 fffff80068eebef5 GMLXDFltr+0x1a08 01 fffff5040ab56450 fffff800692f753e nt!IofCallDriver+0x55 02 fffff5040ab56490 fffff800692f2874 nt!IopParseDevice+0x8be 03 fffff5040ab56660 fffff800692f1222 nt!ObpLookupObjectName+0x1104 04 fffff5040ab567f0 fffff800692eecb1 nt!ObOpenObjectByNameEx+0x1f2 05 fffff5040ab56920 fffff8006934f438 nt!IopCreateFile+0x431 06 fffff5040ab569e0 fffff8006902bbe5 nt!NtOpenFile+0x58 07 fffff5040ab56a70 00007ffee51af9d4 nt!KiSystemServiceCopyEnd+0x25 08 0000001096acd9d8 00007ffe7209aa32 0x00007ffee51af9d4 09 0000001096acd9e0 0000000000020000 0x00007ffe7209aa32 0a 0000001096acd9e8 0000001096acda10 0x20000 0b 0000001096acd9f0 0000001096acdae0 0x0000001096acda10 0c 0000001096acd9f8 000001420a263498 0x0000001096acdae0 0d 0000001096acda00 0000000000000005 0x000001420a263498 0e 0000001096acda08 0000000000000000 0x5 We can see nt!NtOpenFile in the Call Site column, which is expected, and confirms this is the handle-opening call. Let’s resume the execution and examine the second hit: 3: kd> g GMLXDFltr IRP_MJ_CREATE ran Current Process Image Name: powershell.exe GMLXDFltr+0x1a08: fffff80085a51a08 48895c2408 mov qword ptr [rsp+8],rbx 3: kd> k # Child-SP RetAddr Call Site 00 fffff5040ab56828 fffff80068eebef5 GMLXDFltr+0x1a08 01 fffff5040ab56830 fffff800692f9bdc nt!IofCallDriver+0x55 02 fffff5040ab56870 fffff800692f352e nt!IopDeleteFile+0x13c 03 fffff5040ab568f0 fffff80068eec627 nt!ObpRemoveObjectRoutine+0x7e 04 fffff5040ab56950 fffff800693437d4 nt!ObfDereferenceObjectWithTag+0xc7 05 fffff5040ab56990 fffff800693403a9 nt!ObpCloseHandle+0x2a4 06 fffff5040ab56ab0 fffff8006902bbe5 nt!NtClose+0x39 07 fffff5040ab56ae0 00007ffee51af554 nt!KiSystemServiceCopyEnd+0x25 08 0000001096acd958 00007ffe71e3db77 0x00007ffee51af554 09 0000001096acd960 00007ffe71e06bf0 0x00007ffe71e3db77 0a 0000001096acd968 0000000000000d28 0x00007ffe71e06bf0 0b 0000001096acd970 000001421f783590 0xd28 0c 0000001096acd978 00007ffed10a4bce 0x000001421f783590 0d 0000001096acd980 00004f0250afaf79 0x00007ffed10a4bce 0e 0000001096acd988 00007ffed17b6370 0x00004f0250afaf79 0f 0000001096acd990 0000001096acdb80 0x00007ffed17b6370 10 0000001096acd998 00007ffe71e06bf0 0x0000001096acdb80 11 0000001096acd9a0 00007ffe71e06bf0 0x00007ffe71e06bf0 12 0000001096acd9a8 0000001096acd960 0x00007ffe71e06bf0 13 0000001096acd9b0 00007ffe71e3db77 0x0000001096acd960 14 0000001096acd9b8 0000001096acda00 0x00007ffe71e3db77 15 0000001096acd9c0 00007ffe71e06bf0 0x0000001096acda00 16 0000001096acd9c8 0000001096acdae0 0x00007ffe71e06bf0 17 0000001096acd9d0 000001420a263798 0x0000001096acdae0 18 0000001096acd9d8 000001421f783590 0x000001420a263798 19 0000001096acd9e0 000001420a2590f0 0x000001421f783590 1a 0000001096acd9e8 0000000000000000 0x00000142`0a2590f0 So, the second call is not IRP_MJ_CREATE. It is IRP_MJ_CLOSE (powershell closing the handle), and it comes from NtClose (visible in the Call Site colum). The breakpoint hits twice, because GMLXDFltr uses the same dispatch routine for both MajorCodes.

A glance at the dispatch table confirms this. Both IRP_MJ_CREATE and IRP_MJ_CLOSE are set to GMLXDFltr+0x1a08: 0: kd> !drvobj GMLXDFltr 2 Driver object (ffffd20a9c4cde20) is for: \Driver\GMLXDFltr

DriverEntry: fffff80085a52244 GMLXDFltr DriverStartIo: 00000000 DriverUnload: fffff80085a51b8c GMLXDFltr AddDevice: fffff80085a51ab4 GMLXDFltr

Dispatch routines: [00] IRP_MJ_CREATE fffff80085a51a08 GMLXDFltr+0x1a08 [01] IRP_MJ_CREATE_NAMED_PIPE fffff80085a50388 GMLXDFltr+0x388 [02] IRP_MJ_CLOSE fffff80085a51a08 GMLXDFltr+0x1a08 4.3.2 Per-device and per-class filters Global per-class device filters can be set up in the LowerFilters and UpperFilters entries in the relevant device class registry locations: HKLM:\SYSTEM\CurrentControlSet\Control\Class{GUID}
For example: HKLM:\SYSTEM\CurrentControlSet\Control\Class{4d36e967-e325-11ce-bfc1-08002be10318}\UpperFilters for Disk Drives. The list of well-known GUIDs representing device classes can be found here . As we can see, Storage Volumes, Disk Drives and Storage Disks constitute separate, although similar device classes.

UpperFilters and LowerFilters can also be set up for device nodes more selectively - per instance ID instead of device class. These are located in HKLM\SYSTEM\CurrentControlSet\Enum<instance_ID>. For example: - HKLM\SYSTEM\CurrentControlSet\Enum\SWD\HWID\0001 (SWD for devices created via the Software Device API), - HKLM\SYSTEM\CurrentControlSet\Enum\ROOT\HWID2\0000 (ROOT for root-enumerated devices created through SetupAPI). This provides more flexibility in the ways filters can be run.

We could use a software-emulated device with an FDO that supports IRP_MJ_CREATE only to run the filter on top of it, without creating a Disk Drive device node by mounting a disk. 4.4 Forced driver replacement The real reason for using software-emulated devices as described in the previous sections is to get the driver properly initialized by tricking the PnP manager to call its AddDevice callback with a pointer to a PDO. An alternative to that approach is using one of the devices already existing in the system . So, can we simply force our driver to be installed and loaded for an existing piece of hardware, replacing the original one?

One reason against this approach is system stability. If we force an incorrect driver on a piece of hardware, it is reasonable to assume that hardware will stop functioning correctly. To alleviate that risk we could select a device that is not critical and whose disruption is unlikely to be even noticed. Another potential cause of critical disruption (resulting in system crash) is if the newly loaded driver makes a reference to the PDO’s device extension at some specific offset that exists in the PDO the driver was designed to work with.

So it is a matter of trial and error to find a suitable device node for this purpose. Assuming that the target device is similar enough to the device the vulnerable driver was developed, or the driver is simple enough, it could work (depending on the driver). So, what is stopping us from trying this? During normal driver installation process, forcing an arbitrary driver on an arbitrary device node is problematic because of the hardware ID missmatch.

PnP matches the hardware ID (reported by the bus driver owning the PDO) against all INF files in the local Windows driver repository . PnP will not recognize a driver as correct if the device node’s hardware ID does not match the hardware ID in the corresponding INF file. The INF file is what ties a driver to a specific hardware ID. 4.4.1 The problem with INF files So, can we use a custom INF file, which simply ties FAKEHWID_1234 to AwinicSmartKAmps.sys instead?

Let’s see. First, let’s create a new device node with an arbitrary hardware ID, using create_swdev_cm.c : create_swdev_cm.exe FAKEHWID_1234 Device node created successfully for hardware ID: FAKEHWID_1234 We can inspect it in Device Manager. It appears in the Software Devices group because of the class GUID hardcoded in create_swdev_cm.c, but that can be changed if needed. We can clearly see the arbitrary hardware ID and and that at this stage there is no driver installed for the device: Software device with arbitrary hardware ID and no driver installed Software device with arbitrary hardware ID and no driver installed The PnP manager has not found any matching drivers, because FAKEHWID_1234 is not matched by any INF file from the driver repository.

This is expected. Now, let’s see what happens when we try to update the driver using a minimum custom INF file, tying FAKEHWID_1234 to AwinicSmartKAmps.sys: Custom INF file tying FAKEHWID_1234 to AwinicSmartKAmps.sys If we right-click on the “Unknown device” and invoke “Update driver”, we can manually point the directory with the INF file after choosing: “Browse my computer” -> “Let me pick from a list of available drivers on my computer” -> “Have disk”, we’ll see a warning “This driver is not digitally signed!”: Custom INF file - driver not signed warning If we ignore the warning and click “Next”, we’ll see this: Custom INF file - installation interrupted This is because files in a driver package, including the INF file, are protected by digital signatures defined in the catalog file (.cat). If we remove the CatalogFile = AwinicSmartKAmps.cat line entirely and try again, we will end up with the same outcome and a slightly different error message: Custom INF file - installation interrupted This logic is implemented behind UpdateDriverForPlugAndPlayDevicesW - if we try to do this programmatically instead of using GUI, we will reach the same outcome, with UpdateDriverForPlugAndPlayDevicesW returning relevant error codes. 4.4.2 Bypassing the INF file mechanism If we dig deeper into the PnP architecture, we will discover that what really ties a driver to a device node is dedicated registry structures.

Depending on whether we are creating a new device, or forcing our driver on an existing one, we can either directly create new registry structures or modify the existing ones, to make them reflect the state normally attained with a successful installation, effectively skipping the entire INF mechanism. It boils down to: 1. Deploying the driver with sc.exe create, the standard way. 2.

Choosing the target device (for this test we will create one using SetupAPI). 3. Creating the relevant registry structures in the following locations, tying the driver’s service name to the device: - SYSTEM\CurrentControlSet\Enum\, - SYSTEM\\CurrentControlSet\\Control\\Class\\\\. 4.

Restarting the device (triggers PnP to load the driver). The device instance ID is the full path that uniquely identifies a device in the system and is the actual identifier of a device node. It makes sense when we think about it. The hardware ID only identifies the make and model, and using it as the device node identifier would prevent the OS from supporting multiple devices with the same hardware ID connected to the system at the same time.

Device instance ID has the following form: \\, for example: PCI\VEN_8086&DEV_A370&SUBSYS_02348086&REV_10\3&11583659&0&F5. Instance ID is just the last segment - the part that disambiguates multiple devices with the same enumerator and device ID. In the example above, that's 3&11583659&0&F5. It identifies which physical/logical device this is among devices sharing the same enumerator and device ID.

In our case the device instance ID will be ROOT\SOFTWAREDEVICE\0000, whereas: - ROOT is the enumerator name, - SOFTWAREDEVICE is the device ID (the value comes from uppercase conversion of the string passed as the second argument to SetupDiCreateDeviceInfoW), - 0000 is the instance ID. The instance index, on the other hand, is a zero-based, four-digit sequential number that identifies a specific device instance within a device setup class. Therefore, if no other device instances exist for the given device ID at the time of creation, the instance index will be 0000. Let’s deploy the same driver as earlier using this approach.

First, we create the service in the usual sc.exe create way: sc.exe create AwinicDriver binPath= “C:\runtime_service\AwinicSmartKAmps.sys” type= kernel start= demand [SC] CreateService SUCCESS

sc.exe start AwinicDriver

SERVICE_NAME: AwinicDriver TYPE : 1 KERNEL_DRIVER STATE : 4 RUNNING (STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN) WIN32_EXIT_CODE : 0 (0x0) SERVICE_EXIT_CODE : 0 (0x0) CHECKPOINT : 0x0 WAIT_HINT : 0x0 PID : 0 FLAGS Then, we run the installer (full source code of create_sd_bind_driver.c can be found here ): create_sd_bind_driver.exe FAKEHWID_54321 AwinicDriver {62f9c741-b25a-46ce-b54c-9bccce08b6f2} Device node created: ROOT\SOFTWAREDEVICE\0000 (DevInst=2) Service bound: AwinicDriver Class key created: SYSTEM\CurrentControlSet\Control\Class{62f9c741-b25a-46ce-b54c-9bccce08b6f2}\0003 Driver value set: {62f9c741-b25a-46ce-b54c-9bccce08b6f2}\0003 ConfigFlags set: 0 Restarting device (disable/enable cycle)… Device enabled. AddDevice should have been called. Here are the relevant registry structures after running create_sd_bind_driver.exe: HLLM\SYSTEM\CurrentControlSet\Control\Class{GUID} HKLM\SYSTEM\CurrentControlSet\Enum\ROOT\SOFTWAREDEVICE\0000 By inspecting the device again in the Device Manager, we can clearly see that: - the device was created, - the driver got installed for it, - the device stack got created.

Device working properly Arbitrary hardware ID Device stack built If we look into the Driver tab, we will notice that the driver is “not digitally signed”, which can be a bit misleading: Driver not digitally signed The reason we are seeing this is because there is no INF file and no CAT file tied to this driver in the registry. The .sys file itself is digitally signed, and of course test signing was not enabled at the time of testing: Digital signature valid, no test signing This demonstrates that INF files and their signatures are not a security boundary, but rather a feature meant to prevent INF file abuse (e.g. threat actors backdooring INF files by adding malicious directives, which would then execute with administrative privileges during installation). That makes sense - after all, we did not need INF files to append drivers to the UpperFilters/LowerFilters keys.

And we don’t really need them to tie a driver to a piece of hardware. The same forced installation approach can be performed for already existing devices. We deploy the driver with sc.exe, modify the registry to tie it as the driver for that device, then restart the device. Alternatively, we could even replace the relevant .sys file and restart the device, however that would not work if we are not able to unload the original driver before replacement (because the kernel will not load another module with the same name).

4.5 Working around active hardware probing Passing various hardware probing checks mentioned in section 3.4 Active hardware interaction and probing without the corresponding physical hardware is for the most part possible, but requires either custom kernel mode code (drivers dedicated explicitly for this purpose, especially bus and filter drivers) or hypervisor access. None of these requirements are satisfied in a typical BYOVD scenario. A thorough analysis of hardware interaction mechanisms and the feasibility of spoofing them from user-mode alone is beyond the scope of this article; however, my preliminary assessment suggests that no purely userland technique can generically bypass hardware-gated code paths without loading additional kernel mode components. 5.

Final thoughts While critical vulnerabilities are still quite common in Windows kernel mode drivers, not all drivers with relevant vulnerabilities existing in their code have practical value from the BYOVD perspective due to conditional (usually hardware-dependant) reachability of vulnerable code paths. As I have demonstrated, many of those cases can be worked around by influencing the internal driver state from user-mode by creating software-emulated device nodes with spoofed hardware IDs or forced replacement of drivers for existing hardware. Understanding these caveats can help better assess risks associated with specific device driver vulnerabilities. It is reasonable to assume that at some point in the near future the range of BYOVD-viable drivers will start shrinking due to AI-accelerated vulnerability research and Microsoft removing trust for cross-signed drivers , just to name a few reasons.

Once that starts happening, it may give threat actors the incentive to start taking advantage of vulnerable drivers whose exploitability only seemingly depends on the presence of the corresponding physical hardware, while in practice can be worked around by solely operating from userland. Therefore, it is worth for defenders to pay attention to the forensic footprint associated with the techniques demonstrated in this article. If you want to read similar articles or the predecessor of this article called “Anatomy of Access: device objects from a security perspective”, Click here. Note: This article was thoughtfully written and contributed for our audience Julian Horoszkiewicz, Atos Threat Research Center.

Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Kimwolf DDoS Botnet Operator Arrested in Canada Over DDoS-for-Hire Attacks

The U.S. Department of Justice (DoJ) on Thursday announced the arrest of a Canadian man in connection with allegedly operating a distributed denial-of-service (DDoS) botnet known as Kimwolf . In tandem, Jacob Butler (aka Dort), 23, Ottawa, Canada, has been charged with offenses related to the development and operation of the botnet. Kimwolf is assessed to be a variant of AISURU that specifically infected Android devices with an exposed Android Debug Bridge (ADB) service.

“Kimwolf targeted infected devices which were traditionally ‘firewalled’ from the rest of the internet, such as digital photo frames and web cameras,” the DoJ said . “The infected devices were enslaved by the botnet operators.” “The operators then used a ‘cybercrime-as-a-service’ model to sell access to the infected devices to other cybercriminals. The operators and their customers forced the victim devices to participate in DDoS attacks, targeting computers and servers located throughout the world, including Department of Defense Information Network (DoDIN) IP addresses.” Court documents show that Butler was linked to the administration of the Kimwolf botnet through IP address, online account information, and Discord message records posted by an account called resi[.]to . That Butler was behind the Kimwolf botnet was first exposed by independent security journalist Brian Krebs earlier this February.

At that time, the defendant claimed that he had not used the “Dort” persona since 2021 and that some other party was impersonating him after compromising his old account. The charges come exactly two months after U.S. authorities, in partnership with Canada and Germany, disrupted the command-and-control (C2) infrastructure associated with Kimwolf, AISURU, JackSkid, and Mossad as part of a court-authorized law enforcement operation. Per the DoJ, Kimwolf is estimated to have issued over 25,000 attack commands.

Prior to their takedown, the AISURU/Kimwolf botnets were attributed to some of the record-setting DDoS attacks to date, flooding targets with junk traffic that peaked at 31.4 Terabits per second (Tbps). Besides Butler’s arrest, seizure warrants have been unsealed targeting online services supporting 45 DDoS-for-hire platforms, allowing law enforcement to dismantle them. One of the platforms is said to have collaborated with Kimwolf. Butler has been charged with one count of aiding and abetting computer intrusion.

If convicted, he faces up to 10 years in prison. Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

CISA Adds Exploited Langflow and Trend Micro Apex One Vulnerabilities to KEV

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) on Thursday added two security flaws impacting Langflow and Trend Micro Apex One to its Known Exploited Vulnerabilities ( KEV ) catalog, citing evidence of active exploitation. The vulnerabilities in question are listed below - CVE-2025-34291 (CVSS score: 9.4) - An origin validation error vulnerability in Langflow that could allow an attacker to execute arbitrary code and achieve full system compromise. CVE-2026-34926 (CVSS score: 6.7) - A directory traversal vulnerability in on-premise versions of Trend Micro Apex One that could allow a pre-authenticated local attacker to modify a key table on the server to inject malicious code to deploy to agents on affected installations.

In a report published in December 2025, Obsidian Security said CVE-2025-34291 exploits three combined weaknesses: overly Permissive CORS, lack of cross-site request forgery (CSRF) protection, and an endpoint that allows code execution by design. “The impact is severe: successful exploitation not only compromises the Langflow instance but also exposes all sensitive access tokens and API keys stored within the workspace,” the company noted at the time. “This can trigger a cascading compromise across all integrated downstream services in cloud and SaaS environments.” The vulnerability has since been exploited by an Iranian state-sponsored hacking group named MuddyWater to obtain initial access to target networks, according to a Ctrl-Alt-Intel analysis published in March 2026. As for CVE-2026-34926, Trend Micro said it “observed at least one instance of an attempt to actively exploit one of these vulnerabilities in the wild.” “This vulnerability is only exploitable on the on-premise version of Apex One and a potential attacker must have access to the Apex One Server and already obtained administrative credentials to the server via some other method to exploit this vulnerability,” it added.

In light of active exploitation, Federal Civilian Executive Branch (FCEB) agencies are required to apply the necessary fixes by June 4, 2026, to secure their networks. Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Cisco Patches CVSS 10.0 Secure Workload REST API Flaw Enabling Data Access

Cisco has rolled out updates for a maximum-severity security flaw impacting Secure Workload that could allow an unauthenticated, remote attacker to access sensitive data. Tracked as CVE-2026-20223 (CVSS score: 10.0), the vulnerability arises from insufficient validation and authentication when accessing REST API endpoints. “An attacker could exploit this vulnerability if they are able to send a crafted API request to an affected endpoint,” Cisco said . “A successful exploit could allow the attacker to read sensitive information and make configuration changes across tenant boundaries with the privileges of the Site Admin user.” The shortcoming impacts Cisco Secure Workload Cluster Software on SaaS and on-prem deployments, regardless of device configuration.

Cisco said there are no workarounds that address the vulnerability. The issue has been addressed in the following versions - Cisco Secure Workload Release 3.9 and earlier (Migrate to a fixed release) Cisco Secure Workload Release 3.10 (Fixed in 3.10.8.3) Cisco Secure Workload Release 4.0 (Fixed in 4.0.3.17) The networking equipment major said it found the vulnerability during internal security testing and that there is no evidence of it being exploited in the wild. The disclosure comes a week after Cisco revealed that another maximum-severity authentication bypass flaw in Catalyst SD-WAN Controller ( CVE-2026-20182 , CVSS score: 10.0) has been exploited by a threat actor known as UAT-8616 to gain unauthorized access to SD-WAN systems. Found this article interesting?

Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Showboat Linux Malware Hits Middle East Telecom with SOCKS5 Proxy Backdoor

Cybersecurity researchers have disclosed details of a new Linux malware dubbed Showboat that has been put to use in a campaign targeting a telecommunications provider in the Middle East since at least mid-2022. “Showboat is a modular post-exploitation framework designed for Linux systems, capable of spawning a remote shell, transferring files, and functioning as a SOCKS5 proxy,” Lumen Technologies Black Lotus Labs said in a report shared with The Hacker News. It’s assessed that the malware has been employed by at least one, and possibly more, threat activity clusters affiliated with China, with correlations identified between command-and-control (C2) nodes and IP addresses geolocated to Chengdu, the capital city of the Chinese province of Sichuan. One such threat actor is Calypso (aka Bronze Medley and Red Lamassu), which is known to be active since at least September 2016, targeting state institutions in Brazil, India, Kazakhstan, Russia, Thailand, and Turkey.

It was first publicly documented by Positive Technologies in October 2019. Some of the key tools in its arsenal include PlugX and backdoors like WhiteBird and BYEBY , the latter of which is part of a broader cluster tracked by ESET under the moniker Mikroceen. The use of Mikroceen has been attributed to a closer known as SixLittleMonkeys, which, in turn, shares tactical overlaps with another China-linked group referred to as Webworm . This puts Showboat along with other shared frameworks like PlugX, ShadowPad, and NosyDoor that have been used by multiple China-nexus groups.

This “resource pooling” reinforces the presence of a digital quartermaster that state-sponsored threat actors from China have relied on to supply them with necessary tooling. The starting point of the investigation was an ELF binary that was uploaded to VirusTotal in May 2025, with the malware scanning platform classifying it as a sophisticated Linux backdoor with rootkit-like capabilities. Kaspersky is tracking the artifact as EvaRAT. Black Lotus Labs security researcher Danny Adamitis told The Hacker News that the exact initial access vector used to deliver the malware is currently unknown.

However, in the past, Calypso has been observed leveraging an ASPX web shell after exploiting a flaw or breaking into a default account used for remote access. The adversary was also among the earliest China-aligned groups to weaponize CVE-2021-26855, a security vulnerability in Microsoft Exchange Server that serves as the first step in an exploit chain called ProxyLogon . The malware is designed to contact a C2 server, gather system information, and transmit the information back to the server in a PNG field as an encrypted and Base64-encoded string. It’s also equipped to upload and download files to and from the host machine, conceal its presence from the process list, and manage C2 servers.

To hide itself on the host machine, Showboat retrieves a code snippet hosted on Pastebin. The paste was created on January 11, 2022. Furthermore, the malware can scan for other devices and connect to them via the SOCKS5 proxy. This suggests that the primary purpose of Showboat is to establish a foothold on compromised systems.

“This would allow the attackers to interact with machines that are not exposed publicly to the internet and only accessible via the LAN,” Black Lotus Labs said. Further infrastructure analysis has uncovered two victims: an Afghanistan-based internet service provider (ISP) and another unknown entity located in Azerbaijan. A secondary C2 cluster using similar X.509 certificates as the original C2 server has uncovered two possible compromises in the U.S. and one in Ukraine.

“While some threat actors are increasingly using stealthy, native system tools to evade detection, others still deploy persistent malware implants,” Adamitis said. “The presence of such threats should be taken as an early warning sign, indicating the potential for broader and more serious security issues within affected networks.” Also put to use by Calypso in the campaign targeting the telecommunications provider in Afghanistan is a fully featured Windows implant codenamed JFMBackdoor that’s delivered via DLL side-loading. The attack chain involves a batch script that’s used to launch a legitimate executable that then loads the rogue DLL. JFMBackdoor supports a wide range of capabilities, including remote shell access, file operations, network proxying, screenshot capture, and self-removal.

“The targeting of Afghanistan and its telecommunications sector aligns with what we assess to almost certainly be Red Lamassu’s wider operational goals and objectives,” PricewaterhouseCoopers (PwC) said in a coordinated report. Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

ThreatsDay Bulletin: Linux Rootkits, Router 0-Day, AI Intrusions, Scam Kits and 25 New Stories

This week starts small. A token leaks. A bad package slips in. A login trick works.

An old tool shows up again. At first, it feels like the usual mess. Then you see the pattern: attackers are not always breaking in. They are using the parts we already trust.

That is what makes it worrying. The danger is in normal things now - updates, apps, cloud buttons, support chats, trusted accounts. AI does not make the attacks magic. It just helps people try more things, faster.

Here’s what showed up this week. 47 zero-days exposed 47 0-Days Discovered in Pwn2Own Berlin 2026 The Pwn2Own Berlin 2026 hacking contest has concluded, with security researchers collecting $1,298,250 in rewards after exploiting 47 zero-day flaws in various products from Windows, Linux, VMware, and NVIDIA. DEVCORE won the event with 50.5 Master of Pwn points and $505,000 in rewards throughout the three-day contest after hacking Microsoft SharePoint, Microsoft Exchange, Microsoft Edge, and Windows 11. STARLabs SG and Out Of Bounds followed with $242,500 (25 points) and $95,750 (12.75 points).

Agentic AI security warning U.K. NCSC Issues Guidance for Responsible AI Use The U.K. National Cyber Security Centre (NCSC) has released new guidance for organizations to implement adequate security controls when rolling out agentic artificial intelligence (AI) tools in enterprise environments. “If an agent is over-privileged or poorly designed, a single failure can quickly become a serious incident,” NCSC said .

“It is crucial, therefore, to think before you deploy.” Signal alternative pushed Poland Urges Government Officials to Use Indigenous Signal Alternative The Polish government is urging public officials and “entities within the National Cybersecurity System” to stop using Signal, instead directing them to use an encrypted messenger called mSzyfr developed by a leading Polish research organization, citing social engineering attacks orchestrated by advanced persistent threat (APT) groups. The development comes as multiple governments have warned of a rise in social engineering attacks, including efforts that involve threat actors impersonating Signal support, to take control of victims’ accounts. Fraud suspects unmasked Dutch Police Game Over?! Gets off to a Successful Start The Dutch police said the identity of 74 of 100 suspects has been unmasked following the launch of an initiative called Game Over?!

that displays blurred photos of 100 suspected fraudsters on billboards at various public places, as well as in television and online advertisements, giving the criminals two weeks to surrender before the images are unblurred. Of these, 34 suspects voluntarily reported to authorities, while the remaining suspects were identified through information provided by the public. The youngest suspect is only 14, and the oldest is 42 years old. Game Over?!

was launched in March 2026. Espionage admission President Trump Acknowledges U.S. Spies on China U.S President Donald Trump said he and Chinese President Xi Jinping discussed cyber attacks and espionage activities carried out by both nations during the bilateral meetings last week. “They’re talking about the spying.

Well, we do it too,” Trump said during his return flight to the U.S. “We spy like hell on them too,” adding “I told him, ‘we do a lot of stuff to you that you don’t know about and you’re doing things to us that we probably do know about.’” While Trump did not elaborate on the attacks carried out against China, the acknowledgement comes as China has been accused of conducting sweeping intrusions into U.S. networks. Ransomware hits Korea Gunra Ransomware Goes After South Korea The ransomware family known as Gunra has targeted five South Korean companies since it was first discovered in April 2025, S2W said.

“When Gunra ransomware was first discovered, it utilized Conti-based ransomware,” the South Korean security vendor noted . “However, after transitioning to a RaaS (Ransomware-as-a-Service) model, the group developed and utilized its own ransomware.” As of March 2026, the group has claimed 32 victims. Composer token leak Packagist Urges Composer Update After GitHub Actions Token Leak Composer, a dependency manager for the PHP programming language, has urged its users to update Composer to version 2.9.8 or 2.2.28 (LTS). “The new releases fix a vulnerability where Composer leaks the full contents of GitHub Actions issued GITHUB_TOKEN’s or GitHub App installation tokens to the GitHub Actions logs,” Composer said.

The vulnerability has been assigned the CVE identifier CVE-2026-45793 (CVSS score: 7.5). The development came after GitHub introduced a new format for these tokens as of late last month. “The new format, including a - (hyphen) fails Composer’s validation and leads to disclosure of the GITHUB_TOKEN in logs,” Composer said. As workarounds, it’s advised to disable any GitHub Actions workflow that runs Composer commands until Composer has been updated.

Linux rootkit persists OrBit Linux Malware Is Still Around In July 2022, cybersecurity firm Intezer detailed a Linux malware named OrBit that implements advanced evasion techniques, gains persistence on the machine by hooking key functions, provides the threat actors with remote access capabilities over SSH, harvests credentials, and logs TTY commands. Nearly four years later, several new artifacts of the userland rootkit have been identified, indicating that the malware is being actively refined and maintained by its operators. “We discovered two parallel lineages: a full-featured ‘Lineage A’ build that tracks closely with the 2022 original, and a lite ‘Lineage B’ fork that drops entire capability domains (PAM, pcap, TCP-port hiding) in exchange for a smaller footprint,” researcher Nicole Fishbein said . “Along the way, the operators rotate XOR keys, shuffle install paths, swap backdoor credentials, add auditd-evasion hooks, and eventually bolt on a service-side PAM impersonation primitive.” OrBit has been put to use by Blockade Spider, a cybercrime group running Embargo ransomware campaigns.

It’s assessed that OrBit is a fork of an open-source rootkit called Medusa , which first publicly surfaced in December 2022. “Based on this information, there are two options: either the Medusa author published a privately-circulated rootkit source that had already been deployed operationally, or the earliest OrBit sample was built from a pre-publication snapshot of the same tree,” Intezer said. “Either way, the 2022 OrBit sample and the December 2022 Medusa source tree are the same codebase. This suggests that the backdoor was created before its public release and has since been selectively forked, configured, and redeployed by multiple operators over four years.” AI-driven intrusions surge 2 Vibe Hacking Campaigns Target Governments and Financial Orgs in Latin America Two emerging campaigns, dubbed SHADOW-AETHER-040 and SHADOW-AETHER-064, have independently deployed agentic AI with “strikingly similar tactics” to facilitate intrusion operations against governments and financial organizations in Latin America.

“Both campaigns established traffic tunnels to victim systems, enabling AI agents to conduct malicious attacks directly into victim internal network environments via ProxyChains and SSH,” Trend Micro said . “The AI agents dynamically generated multiple hacking tools and scripts, rather than relying on pre-built hacking tools. This reduced the likelihood of detection by traditional security solutions that rely on known tool signatures.” The two activity clusters are said to be the work of separate entities. The attackers bypassed AI safety controls by framing their requests as authorized penetration testing and red teaming exercises.

Undertaken by a Spanish-speaking threat actor, SHADOW-AETHER-040 has compromised six government entities in Mexico between December 27, 2025, and January 4, 2026. This activity is consistent with Gambit Security’s report about large-scale compromise of multiple Mexican government organizations between December 2025 and February 2026 by an unknown adversary using Anthropic’s Claude and OpenAI’s GPT AI models to carry out the intrusion activities. According to Dragos, which is tracking the activity as TAT26-12, one of these attacks targeted a municipal water and drainage utility in January 2026, leading to an unsuccessful attempt to breach its operational technology environment. “Claude acted as the primary technical executor and independently identified the OT environment’s relevance to critical infrastructure, assessed its potential as a crown jewel asset, and investigated possible access pathways to breach the IT-OT boundary,” Dragos said .

The second campaign, linked to a Portuguese-speaking hacking crew named SHADOW-AETHER-064, has been active since April and has singled out financial organizations in Brazil. The findings show how commercial AI tools are compressing the traditional attack kill chain, accelerating tasks like reconnaissance and exploit development that historically required significant time and operator expertise. Like in the case of VoidLink , while the tools assembled for these attacks may not be particularly sophisticated or novel, the speed at which AI models generate and improve upon them is operationally significant, essentially collapsing what would have taken days or weeks of manual development effort into hours. Mythos intel sharing expands Anthropic Lets Mythos Preview Users Share Threat Intel According to the Wall Street Journal, Anthropic has begun letting users of its Mythos AI model share cybersecurity threats with others who may face similar vulnerabilities.

“Last week, Anthropic began telling the companies they could share information about cyber threats and Mythos findings with other entities as long as it was done responsibly,” a spokesperson for the company was quoted as saying. “As the program has matured, we’ve adapted them to ensure key information can be shared broadly - including outside the program - for maximum defensive impact.” The development comes as Cloudflare said Mythos is a “real step forward” and is capable of chaining “small attack primitives together into a working exploit.” It’s also equipped to find vulnerabilities and prove they are exploitable. The web infrastructure and security company also said it has designed a multi-stage vulnerability discovery harness to scan codebases across “runtime, edge data path, protocol stack, control plane, and the open-source projects we depend on.” Just like Microsoft’s MDASH, different agents handle different responsibilities: “hunter” agents identify candidate vulnerabilities, others argue for or against their exploitability, while a deduplication stage collapses findings that share the same root cause. A tracer agent checks whether attacker-controlled input actually reaches the bug from outside the system, while a final “reporting” agent writes a structured report.

Calls now encrypted Discord Rolls Out E2EE for Voice, Video calls Discord has announced that all voice and video calls through the communication platform are now protected by default with end-to-end encryption (E2EE). The solution is powered by the DAVE protocol. “The DAVE protocol is open, and the implementation is open-source ,” Discord said. “As of early March 2026, every voice and video call on Discord, whether in DMs, group DMs, voice channels, or Go Live streams, is end-to-end encrypted by default.” Discord said there are no plans to extend it to text messages.

“Many of the features people use on Discord were built on the assumption that text isn’t end-to-end encrypted, and rebuilding them to work with encryption is a meaningful engineering challenge,” it added. Azure identities abused Storm-2949 Abuses Self-Service Password Reset for Azure Data Theft Attacks Microsoft has shed light on a “methodical, sophisticated, and multi-layered attack” orchestrated by Storm-2949 with an aim to exfiltrate sensitive data from an unnamed organization’s high-value assets. The attack, which is notable for abusing Microsoft’s Self-Service Password Reset ( SSPR ) process to trick the target into completing multi-factor authentication (MFA) prompts, led to the exfiltration of data from Microsoft 365 applications, file-hosting services, and Azure-hosted production environments. The social engineering attack targeted IT personnel and senior leadership so as to compromise their identities for post-compromise actions.

The attacker is also said to have conducted discovery activities, installed ScreenConnect, and attempted to disable Microsoft Defender Antivirus protections. “Storm-2949 didn’t rely on traditional malware and other on-premises tactics, techniques, and procedures (TTPs),” Microsoft said . “Instead, they leveraged legitimate cloud and Azure management features to gain control-plane and data-plane access, which they then used to execute code remotely on VMs, and access sensitive cloud resources such as Key Vaults and storage accounts, among others. These activities allowed them to move laterally across cloud and endpoint environments while blending into expected administrative behavior.” App Store fraud blocked Apple Blocked 2M Problematic Apps in 2025 Apple said its App Store stopped over $2.2 billion in potentially fraudulent transactions and rejected over 2 million problematic app submissions in 2025.

“Last year, Apple’s systems also successfully rejected 1.1 billion fraudulent customer account creations - blocking bad actors at the outset - and deactivated an additional 40.4 million customer accounts for fraud and abuse,” Apple said . “In 2025, Apple terminated 193,000 developer accounts over fraud concerns and rejected more than 138,000 developer enrollments. To further protect users from harmful software, Apple in 2025 detected and blocked 28,000 illegitimate apps on pirate storefronts, which include malware, pornography apps, gambling apps, and pirated versions of legitimate apps from the App Store.” Apple also rejected over 22,000 submissions for containing hidden or undocumented features and more than 443,000 submissions for privacy violations. In the last month alone, the iPhone maker said it prevented 2.9 million attempts to install or launch apps distributed illicitly outside the App Store or approved alternative app marketplaces.

Fraud routing exposed Two Plead Guilty to Tech-Support Fraud Scheme Two U.S. nationals, CEO Adam Young, 42, of Miami, and Harrison Gevirtz, 33, of Las Vegas, have pleaded guilty to running a business that provided services to customers engaged in widespread telemarketing and tech-support fraud schemes targeting victims across the country. The services, which included telephone numbers, call routing services, call tracking, and call forwarding services, were offered to customers who engaged in tech-support fraud schemes. They are scheduled to be sentenced on June 16, 2026.

The investigation also led to the conviction of five India-based telemarketing fraudsters and a former employee of their call routing company (Sahil Narang, Chirag Sachdeva, Abrar Anjum, Manish Kumar, and Jagmeet Singh Virk) for targeting and defrauding Americans. “Call centers based in India utilized Young and Gervitz’s business to route their ‘tech fraud’ scheme calls and, in some instances, advised those fraudsters on methods intended to reduce complaints and prevent account terminations,” the U.S. Justice Department said . The schemes used deceptive pop-up messages to falsely convince users that their computers had been infected with viruses or malware, urging them to contact a number to address the issue.

In reality, the numbers connected the victims to call centers, where they were duped into paying hundreds of dollars for unnecessary or fictitious technical-support services. In some instances, the call center agents gained remote access to victims’ computers and obtained personal and financial information. Linux printing RCE risk HP Fixes Critical Flaw in Linux Imaging and Printing (HPLIP) Software HP has released fixes for CVE-2026-8631 (CVSS score: 9.3), a critical heap-based buffer overflow vulnerability in HPLIP that could allow escalation of privileges and/or arbitrary code execution. “Because HPLIP is deeply integrated into the standard Linux printing architecture (CUPS), this flaw exposes millions of Linux endpoints and enterprise print servers,” security researcher Mohamed Lemine Ahmed Jidou, who discovered the flaw, told The Hacker News.

“An unauthenticated attacker over the network - or a low-privileged local user - can silently exploit this by simply submitting a maliciously crafted print job. Successful exploitation grants the attacker arbitrary command execution on the host machine. This allows for immediate system compromise, unauthorized access to sensitive documents passing through the print spooler, and provides a stealthy foothold for lateral movement across corporate networks.” Telegram accounts hijacked Telegram Smishing Campaign Facilitates Account Takeovers AhnLab is warning of a new Telegram-oriented smishing campaign that’s designed to take control of victims’ accounts and steal account information using SMS messages that claim to be about non-existent security issues. “Threat actors hijack Telegram accounts by tricking users into entering their phone numbers and login codes on phishing sites,” AhnLab said .

“Once an account is compromised, it can lead to personal information and chats being leaked, as well as secondary damage.” Premium SMS fraud Android Android Carrier Billing Fraud Campaign Uncovered A new sophisticated Android malware campaign dubbed Premium Deception has been observed conducting carrier billing fraud through premium SMS abuse across Malaysia, Thailand, Romania, and Croatia between March 2025 and January 2026. The activity involves more than 250 malicious applications that selectively target users based on their mobile operator, stealthily subscribing users to premium services without their knowledge or consent by abusing Google’s SMS Retriever API to capture OTPs for billing confirmation. Device metadata and subscription confirmations are sent to the operators via a Telegram-based exfiltration channel. “When deployed on devices with non-targeted operators, the malware employs a fallback mechanism to display benign content, thereby evading detection and maintaining persistence,” Zimperium zLabs said .

Three distinct malware variants have been identified, each with varying levels of sophistication. There is no evidence that these apps were circulated via the Google Play Store. Instead, the scheme relies on social media platforms like Facebook and TikTok for distribution. Brazilian banking RAT Banana RAT Targets Brazilian Banks A new Brazilian banking trojan dubbed Banana RAT has become the latest malware to target financial institutions in the region.

Unlike other Latin American banking malware that are typically written in Delphi, Banana RAT is a PowerShell-only client orchestrated by a Python (FastAPI) server-side polymorphism engine. Once active, it enables operator-driven fraud through remote input control, keylogging, clipboard monitoring, screen streaming, fake overlays, and Pix QR code interception targeting Brazilian banks. It also monitors foreground window titles and serves a bogus credential harvesting overlay when a victim opens a website that matches a target list of more than 30 bank and cryptocurrency exchanges. Trend Micro, which is tracking the activity under the moniker SHADOW-WATER-063 , said the design diverges “meaningfully” from the Delphi binary architecture historically associated with the banking malware ecosystem comprising Grandoreiro, Mekotio, Casbaneiro, Guildma, and CHAVECLOAK.

“The Brazilian cybercrime cartels are very sophisticated and organized, and they have been a bane to the financial sector since 2000,” Tom Kellermann, TrendAI’s vice president of AI Security and Threat Research, said. “The RATs and rootkits they develop are on par with those we have seen from Russia. Insufficient attention is being paid to cybercrime in LATAM, and the financial sector has good reason to be concerned as something wicked comes this way.” DNS-backed Go backdoor Go Typosquat Library Uses DNS TXT Records as a Command Channel A malicious Go module published as github.com/shopsprint/decimal has been flagged as a typosquat of the widely used github.com/shopspring/decimal arbitrary precision arithmetic library. It was first published in November 2017 and was weaponized in August 2023 when version v1.3.3 added a malicious functionality that “opens a DNS TXT record command-and-control channel to a threat actor-controlled subdomain on a free dynamic DNS provider,” per Socket.

Although the GitHub repository and the shopsprint owner account have since been removed, the library continues to be served by proxy.golang[.]org. The payload “polls net.LookupTXT(“dnslog-cdn-images.freemyip.com”) every five minutes, and sleeps on DNS failure without logging or signaling an error,” researcher Kush Pandya said . “Each returned TXT value is passed directly to os/exec.Command and executed.” npm package hijacked art-template Compromised to Serve Coruna iOS Exploit Kit The npm package art-template, a JavaScript template engine with about 26,000 weekly downloads, has been compromised through a maintainer account takeover to push malicious versions (from 4.13.3 through 4.13.6) designed to load external JavaScript from third-party domains. “Unauthorized code in template-web.js injects external

“The external domain (v3.jiathis[.]com) serves a multi-stage payload when the request includes a Referer header. The payload injects Baidu Analytics tracking on all visitors and targets iPhone users with a hidden iframe chain leading to an obfuscated JavaScript payload. The final payload is the Coruna exploit kit .” Malware game removed Steam Removes Game That Served Malware A malicious game distributed through Steam has been removed from Valve after it was observed profiling players’ systems and communicating with external infrastructure that allows it to deploy secondary payloads. The game, titled Beyond The Dark, masqueraded as a free indie horror title on Steam.

The discovery was documented by YouTuber Eric Parker. Router zero-day outage Luxembourg Nationwide Telecom Outage Linked to Huawei Router 0-Day The exploitation of a zero-day vulnerability in Huawei enterprise router software led to a nationwide telecom outage in Luxembourg on July 23, 2025, The Record reported this week. The incident disrupted mobile, landline, and emergency communications for more than three hours. The attack is said to have caused Huawei enterprise routers to enter into a continuous restart loop, crashing parts of POST Luxembourg’s infrastructure.

There are currently no details about the vulnerability, and it remains unclear if the issue was patched by Huawei. Crypto ATM losses surge FBI Says $388M Lost in Crypto ATM Scams in 2025 The U.S. Federal Bureau of Investigation (FBI) has revealed that Americans have lost over $388 million last year to scams using cryptocurrency kiosks (aka crypto ATMs or Bitcoin ATMs). “Cryptocurrency kiosks are ATM-like devices or electronic terminals that allow users to exchange cash and cryptocurrency,” the FBI said .

“Criminals may direct victims to send funds via cryptocurrency kiosks.” The development comes as CertiK noted that physical coercion attacks (aka wrench attacks ) on cryptocurrency holders rose 75% year-over-year to 72 confirmed cases worldwide and $41 million in known losses in 2025, up 44% from 2024. This year alone, 34 verified incidents have been recorded internationally, compared to 24 over the same period in 2025. ICS attacks persist Sandworm’s Targeting of Industrial Environments Operational technology security company Nozomi Networks said it detected 29 events between July 2025 and January 2026 that “conclusively identified as Sandworm activity.” Based on data collected from customer and partner engagements, honey research, and telemetry, the activity follows a bureaucratic execution model, “peaking midweek and during post-lunch business hours, with Wednesday at approximately 2:00 PM Moscow time showing the highest alert volume.” Across the dataset, 17 Sandworm-infected machines were identified across the 10 customers. These systems conducted lateral movement against 923 unique internal targets.

“Despite widespread awareness and patch availability, Sandworm continues to rely on older but proven exploit chains, including EternalBlue, DoublePulsar, and WannaCry,” Nozomi Networks said . “Perhaps the most critical finding: every single Sandworm-infected system produced 20 to 155 days of warning alerts prior to Sandworm activity.” Stego loader deployed Phishing Campaign Delivers PureLogs Stealer A new phishing campaign has been observed using invoice-themed lures to distribute malicious archives to trigger the execution of JavaScript code, which employs environment variables to hide malicious commands and uses a steganographic loader dubbed PawsRunner to deploy the PureLogs infostealer malware. “The embedded JavaScript uses a sophisticated technique to store decoded malicious commands in environment variables, which then triggers a decrypted steganographic .NET loader,” Fortinet said . “This loader retrieves the final payload by extracting encrypted data hidden within a cat image.

This version of PureLogs uses extensive async/await patterns to improve task efficiency and complicate analysis.” A similar campaign was detailed by Swiss Post Cybersecurity in January 2026. Card dump released B1ack’s Stash Releases 4.6 Million Stolen Credit Cards for Free The notorious B1ack’s Stash dark web carding marketplace has announced the free download of 4.6 million stolen credit card records. According to SOCRadar , the released data includes full card numbers, expiration dates, CVV2 codes, cardholder names, billing addresses, email addresses, phone numbers, and IP addresses. Of these, 4.3 million records appear to be new and usable for illicit activities.

Most of the records belong to victims from the U.S., Canada, the U.K., France, and Malaysia. Browser-locking scareware New CypherLoc Browser-Locking Shareware Emerges A new web-based scareware kit called CypherLoc is capable of combining “advanced evasion, aggressive browser controls, and psychological manipulation” to drive victims into calling fraudulent tech support phone numbers. Barracuda Networks said it has observed around 2.8 million attacks featuring the kit since the start of 2026. “The attack usually starts with a phishing email that directs the victim to a malicious web page through a link that is either embedded in the email body or in an attachment,” Barracuda said .

“The web page initially appears harmless but gradually transitions into a fully controlled scareware environment. The trigger for this transition is hidden in the web page and will only decrypt if certain conditions are met.” The end result is a full-screen scareware interface that locks the browser and displays fake security messages that urge victims to contact support immediately. AI phishing at scale Generative AI-Enabled Attacks Against Individuals via Public Social Media Data New research has demonstrated that “publicly available social-media data and generative AI (GenAI) can be misused to automate and scale highly personalized, context-aware spear-phishing campaigns.” Researchers from the University of Texas at Arlington and Louisiana State University, Baton Rouge, said a “small amount of public activity per target” is enough for AI models to extract interests and contextual cues that could be exploited to carry out persuasive phishing campaigns that mirror a target’s style. The findings show that bad actors do not have to rely on stolen databases or extensive reconnaissance to carry out targeted phishing campaigns.

Legacy LOLBIN abused Microsoft MSHTA Still in Use in Malware Campaigns Bitdefender haș disclosed that attackers are continuing to exploit Microsoft HTML Application Host (MSHTA), a legacy utility available by default on Windows systems, for malware campaigns. “MSHTA remains a widely abused Living-off-the-Land binary (LOLBIN) despite being a legacy utility,” Bitdefender said . “Attackers use it across multiple malware categories, from commodity stealers to advanced threats. Campaigns frequently rely on multi-stage, fileless execution chains involving PowerShell and HTA scripts.” MSHTA has been abused in delivery chains for commodity stealers such as Lumma Stealer and Amatera, loaders such as CountLoader and Emmenhtal Loader (aka PEAKLIGHT), clipper malware, and more advanced threats like Purple Fox .

GovCloud secrets exposed CISA Leaves AWS GovCloud Keys Exposed on GitHub A contractor for the U.S. Cybersecurity and Infrastructure Security Agency (CISA) maintained credentials to several highly privileged AWS GovCloud accounts and a large number of internal CISA systems exposed on a public GitHub repository (ironically named “Private-CISA”) since November 2025. The repository was discovered by GitGuardian on May 14, 2026. It harbored 844 MB of plain-text passwords, AWS tokens, and Entra ID SAML certificates belonging to the agency.

The repository has since been pulled offline following responsible disclosure. There is no evidence that any sensitive data was compromised as a result of this incident. Trojanized apps cluster Tracking TamperedChef Clusters Palo Alto Networks Unit 42 said it has identified 4,000 samples across 100 unique variants associated with a threat known as TamperedChef (aka EvilAI), which involves using trojanized versions of productivity software to deliver malicious payloads using malicious ads that direct users to sites hosting the applications. “TamperedChef-style malware samples share characteristics with potentially unwanted programs (PUPs) and adware,” Unit 42 said .

“These include robust mechanisms to remain persistent, and end-user licensing agreements (EULAs) that attempt to legally cover the software’s questionable actions. However, TamperedChef-style malware is far more stealthy than PUPs or adware, remaining dormant for weeks to months before activating. This includes continuous command and control (C2) methods enabling adversaries to retrieve additional payloads, such as information stealers, proxy tooling or remote access Trojans (RATs).” The activity has been attributed to three distinct clusters distributing malicious apps since early 2023: CL-CRI-1089 (Calendaromatic, DocuFlex, and AppSuite PDF), CL-UNK-1090 (CrystalPDF, Easy2Convert, and PDF-Ezy), and CL-UNK-1110 (JustAskJacky, GoCookMate, RocketPDFPro, ManualReaderPro). While CL-CRI-1089 appears to target credentials and deploy adware and proxy-style payloads, the motivations of the other two clusters are unknown.

That’s the problem with weeks like this. Nothing feels shocking for more than five minutes, because the next thing is already waiting. A fake app here, a bad package there, a cloud trick in the middle. Same fire, new room.

Patch what matters. Watch what you trust. And do not ignore the boring alerts just because they look familiar. That is usually where the story starts.

Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Microsoft Warns of Two Actively Exploited Defender Vulnerabilities

Microsoft has disclosed that a privilege escalation and a denial-of-service flaw in Defender has come under active exploitation in the wild. The former, tracked as CVE-2026-41091 , is rated 7.8 on the CVSS scoring system. Successful exploitation of the flaw could allow an attacker to gain SYSTEM privileges. “Improper link resolution before file access (‘link following’) in Microsoft Defender allows an authorized attacker to elevate privileges locally,” Microsoft said in an advisory.

The second vulnerability under exploitation is CVE-2026-45498 (CVSS score: 4.0), a denial-of-service bug impacting Defender. The two vulnerabilities have been addressed in Microsoft Defender Antimalware Platform versions 1.1.26040.8 and 4.18.26040.7, respectively. Although Microsoft has not formally confirmed, the vulnerability descriptions for CVE-2026-41091 and CVE-2026-45498 overlap with that of RedSun and UnDefend , two Defender zero-days that were disclosed by Chaotic Eclipse (aka Nightmare-Eclipse) last month. Huntress has since observed exploitation of both the vulnerabilities, alongside BlueHammer (CVE-2026-33825).

Also addressed in version 1.1.26040.8 is a heap-based buffer overflow vulnerability in Defender ( CVE-2026-45584 , CVSS score: 8.1) that an unauthorized attacker could exploit to achieve remote code execution. There is no evidence the vulnerability has been exploited in the wild. The tech giant noted that systems that have disabled Microsoft Defender are not susceptible to the vulnerabilities, adding that no action is required to install the update since it automatically updates malware definitions and the Microsoft Malware Protection Engine for optimal protection. Microsoft credited five different parties with discovering and reporting CVE-2026-41091, including Sibusiso, Diffract, Andrew C.

Dorman (aka ACD421), Damir Moldovanov, and an anonymous researcher. To ensure the latest version of the Microsoft Malware Protection Platform and definition updates are being actively downloaded and installed, users are recommended to follow the steps below: Open the Windows Security program. In the navigation pane, select Virus & threat protection . Then click on Protection Updates in the Virus & threat protection section updates.

Select Check for updates . In the navigation pane, select Settings , and then select About . Examine the Antimalware ClientVersion number. The U.S.

Cybersecurity and Infrastructure Security Agency (CISA) has added both CVE-2026-41091 and CVE-2026-45498 to its Known Exploited Vulnerabilities ( KEV ) catalog, requiring Federal Civilian Executive Branch (FCEB) agencies to apply the fixes by June 3, 2026. With the latest development, a total of three Microsoft vulnerabilities have been flagged as exploited within a span of a week. Last week, Redmond disclosed that a cross-site scripting flaw impacting on-premise versions of Exchange Server (CVE-2026-42897, CVSS score: 8.1) had been weaponized in real-world attacks. Also added to the KEV catalog on Wednesday are four other Microsoft flaws from 2008, 2009, and 2010 - CVE-2010-0806

• Microsoft Internet Explorer contains a use-after-free vulnerability that could allow remote attackers to execute arbitrary code.

CVE-2010-0249

• Microsoft Internet Explorer contains a use-after-free vulnerability that could allow remote attackers to execute arbitrary code. CVE-2009-1537
• Microsoft DirectX contains a NULL byte overwrite vulnerability in the QuickTime Movie Parser Filter in quartz.dll in DirectShow, which could allow remote attackers to execute arbitrary code via a crafted QuickTime media file. CVE-2008-4250
• Microsoft Windows contains a buffer overflow vulnerability in the Windows Server Service that allows remote attackers to execute arbitrary code via a crafted RPC request. Another vulnerability that finds a mention in the list is CVE-2009-3459 , a heap-based buffer overflow vulnerability in Adobe Acrobat and Reader that could allow remote attackers to execute arbitrary code via a crafted PDF file that triggers memory corruption.

Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

When Identity is the Attack Path

Consider a cached access key on a single Windows machine. It got there the way most cached credentials do - a user logged in, and the key stored itself automatically. Standard AWS behavior. No one misconfigured anything or violated a policy.

Yet that single key, which was easily accessible to a minor-league attacker, could have opened a path to some 98% of entities in the company’s cloud environment - nearly every critical workload the business depended on. This real-world exposure was caught before an attacker could use it. But the takeaway is clear: identity itself, and every permission it carries, has become the attack path. Your environment runs on identity.

Active Directory, cloud identity providers, service accounts, machine identities, and AI agents - all of these carry permissions that span systems and trust boundaries. A single stolen credential hands the attacker a legitimate identity - along with every permission attached to it. Despite this, most security programs still treat identity as a perimeter control - something to protect through authentication and access policies. Yet the real risk starts inside the front door.

Once an attacker has a foothold, identity is what lets them advance, cross boundaries, and reach critical assets. Because identity is not a perimeter - it’s a highway that runs through every layer of your environment. In this article, we’ll look at how cached credentials, excessive permissions, and forgotten role assignments can turn into attack paths across hybrid environments - and why the tools designed to catch them keep missing. The Attack Path Runs Through Identity The cached access key from that opening scenario is just one example of a much larger phenomenon.

Across hybrid environments, identity One Active Directory group membership that no one reviewed gives an attacker on a retail endpoint a direct path to the corporate domain. A developer SSO role provisioned for a cloud migration keeps its permissions long after the project wraps, giving anyone who compromises that identity a four-step route from developer access to production admin. What makes these real-world examples so dangerous is how they connect. That cached credential on the retail endpoint led to an overprivileged role in Active Directory, which led to a cloud workload with an attached admin policy.

Together, the links in this type of identity exposure chain form a single attack path - from an initial foothold to a critical asset. How prevalent is this? Palo Alto found that identity weaknesses played a serious role in nearly 90% of its 2025 incident response investigations . And given the prevalence of AI agents taking on enterprise workloads, those numbers are likely to go up.

SpyCloud’s 2026 Identity Exposure Report flagged non-human identity theft as one of the fastest-growing categories in the criminal underground, with a third of recovered non-human credentials tied to AI tools. What happens when one of those non-human identities carries admin-level permissions? Consider a dev team that configures an MCP server with high-level permissions so their AI tooling can operate across systems. The AI agent using the MCP server inherits those privileges as its own identity.

A vulnerability in the open-source tooling can easily hand an attacker the permissions that agent holds. From there, the path runs straight into cloud resources, databases, and production infrastructure. The credentials that make this possible are exactly the kind found circulating in criminal marketplaces by the millions. Why the Tools Keep Missing Clearly, the threat of identity exposures is not a new one.

Yet the identity tools most organizations still rely on were built to solve specific problems in isolation – and in a different threat era. IGA platforms manage user lifecycle - provisioning, deprovisioning, access reviews, and more. PAM solutions store privileged credentials and monitor sessions. Each of these tools does its job in isolation.

But none of them can map how identity exposures chain together across endpoints, Active Directory, and cloud environments into a single exploitable route. This is why the rates of identity-based incidents keep climbing even as security spending grows. The IBM X-Force 2026 Threat Intelligence Index found that stolen or misused credentials accounted for 32% of incidents - the second most common initial access vector. Today’s attackers really don’t need to write malware or exploits, they can just log in.

The vast majority of these identity-based exposures are entirely preventable. In fact, Palo Alto found that over 90% of the breaches its teams investigated in 2025 were enabled by exposures that existing tools should have caught. The organizations had the tools and the staff. Yet the gaps persisted because no single tool had visibility into how identity exposures chained together across environments into attack paths.

Closing the Gap Until security programs can connect identity, permissions, and access controls into a unified view of how an attacker actually moves, identity will remain one of the easiest ways to compromise critical assets. Every scenario in this article follows the same structure: a credential, permission, or role assignment that no single tool flags as dangerous creates a traversable path from a low-level foothold to a critical asset. The path only becomes visible when identity, access policies, and environment context are mapped together. Security programs that map those connections across hybrid environments can close identity-based attack paths before an attacker chains them.

Programs that keep treating identity as a perimeter problem will continue losing ground to attackers who already know it’s a highway. Note: This article was thoughtfully written and contributed for our audience by Alex Gardner , Director of Product Marketing at XM Cyber Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

9-Year-Old Linux Kernel Flaw Enables Root Command Execution on Major Distros

Cybersecurity researchers have disclosed details of a vulnerability in the Linux kernel that remained undetected for nine years. The vulnerability, tracked as CVE-2026-46333 (CVSS score: 5.5), is a case of improper privilege management that could permit an unprivileged local user to disclose sensitive files and execute arbitrary commands as root on default installations of several major distributions like Debian, Fedora, and Ubuntu. It’s also codenamed ssh-keysign-pwn. According to Qualys, which discovered the flaw, the problem is rooted in the kernel’s __ptrace_may_access() function and was introduced in November 2016.

“The primitive is reliable and turns any local shell into a path to root or to sensitive credential material,” Saeed Abbasi, senior manager of Threat Research Unit at Qualys, said . Successful exploitation of the flaw could permit a local attacker to disclose /etc/shadow and host private keys under /etc/ssh/*_key, as well as execute arbitrary commands as root through four different exploits targeting chage, ssh-keysign, pkexec, and accounts-daemon. The disclosure comes as a proof-of-concept (PoC) exploit for the vulnerability was released last week, shortly after a public kernel commit emerged. CVE-2026-46333 is the latest security vulnerability disclosed in the Linux kernel after Copy Fail, Dirty Frag , and Fragnesia over the past month.

It’s recommended to apply the latest kernel update released by Linux distributions. If the updates cannot be carried out immediately, temporary workarounds include raising “kernel.yama.ptrace_scope” to 2. “On hosts that have allowed untrusted local users during the exposure window, treat SSH host keys and locally cached credentials as potentially disclosed,” Qualys said. “Rotate host keys and review any administrative material that lived in the memory of set-uid processes.” The development follows the release of a PoC for a local privilege escalation flaw called PinTheft that allows local attackers to gain root privileges on Arch Linux systems.

The exploit requires the Reliable Datagram Sockets (RDS) module to be loaded on the target system, io_ring to be enabled, a readable SUID-root binary, and x86_64 support for the included payload. “PinTheft is a Linux local privilege escalation exploit for an RDS zerocopy double-free that can be turned into a page-cache overwrite through io_uring fixed buffers,” Zellic and the V12 security team said . “The bug lived in the RDS zerocopy send path. rds_message_zcopy_from_user() pins user pages one at a time.

If a later page faults, the error path drops the pages it already pinned, and later RDS message cleanup drops them again because the scatterlist entries and entry count remain live after the zcopy notifier is cleared. Each failed zerocopy send can steal one reference from the first page.” Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.