The Quiet Threat Hiding in Plain Sight

At least two distinct threat actors are now weaponizing a novel evasion technique called OAuth client ID spoofing in cloud campaigns, and they’re slipping past telemetry while doing it. This isn’t a theoretical flaw or a researcher’s proof-of-concept. It’s active, in the wild, and it’s giving attackers a way to poke at Microsoft Entra ID environments without leaving the usual digital footprints.

The core trick? It lets attackers enumerate user accounts and validate stolen credentials in Microsoft Entra ID environments without ever generating a successful sign-in event. That’s the kind of thing that keeps security teams up at night, because the very logs they rely on — the sign-in logs, the anomaly detection, the risk scoring — simply never fire.

How OAuth Client ID Spoofing Works

OAuth is the backbone of modern identity federation. When an app wants to access resources on behalf of a user, it presents a client ID and requests a token. The client ID is supposed to identify the application making the request. But what happens when an attacker crafts a request that looks like it’s coming from a legitimate, trusted application?

That’s the essence of the spoof. By manipulating the OAuth flow, attackers can trick the identity provider into processing authentication attempts as if they came from a benign client. The result: the system validates the credentials — checking whether a username and password pair is correct — but never completes a full sign-in, so no successful sign-in event is logged.

The Two-Stage Attack Chain

Researchers who tracked the activity describe a two-stage process that’s both simple and effective:

• Stage one: Account enumeration. The attacker sends a series of OAuth requests with spoofed client IDs to determine which usernames exist in the tenant. Each response reveals whether the account is valid, without triggering any lockout or alert.
• Stage two: Credential validation. Once valid usernames are identified, the attacker runs stolen password lists through the same spoofed OAuth flow. A successful response confirms the credentials are good — again, with no sign-in log entry to raise suspicion.

This two-step approach means attackers can quietly build a list of valid accounts and verified passwords, then use that intel for later, more damaging attacks — like data exfiltration or lateral movement.

Why Traditional Defenses Miss It

Most identity protection tools rely heavily on sign-in logs to detect anomalous behavior. Failed sign-ins, impossible travel, unusual locations — these are the bread and butter of threat detection. But if the attack never produces a sign-in event, those tools have nothing to chew on.

That’s the real danger here. The technique was designed to evade telemetry, and it does so effectively. Security information and event management (SIEM) systems, cloud access security brokers (CASBs), and even Microsoft’s own conditional access policies can be blindsided if they’re not specifically looking for this pattern of OAuth traffic.

What This Means for Security Teams

If you’re responsible for a Microsoft Entra ID tenant, this isn’t a time for panic — it’s a time for action. There are concrete steps you can take to reduce your exposure:

• Audit your OAuth applications. Review every application registered in your tenant. Remove any that are unused, and scrutinize any with broad permissions.
• Monitor OAuth traffic specifically. Don’t rely solely on sign-in logs. Look for patterns in token requests, especially from unfamiliar client IDs.
• Enable conditional access policies. Restrict which applications can request tokens, and require step-up authentication for sensitive operations.
• Watch for enumeration patterns. A sudden spike in OAuth requests, even if they’re not successful sign-ins, can be an early indicator of this technique.

It’s also worth revisiting your incident response playbook. If an attacker has already validated credentials, the clock is ticking. You need a process for detecting and responding to this kind of quiet reconnaissance before it escalates.

The Bigger Picture: Cloud Identity Security

This discovery is a reminder that identity is the new perimeter — and that the perimeter is getting harder to defend. Attackers are constantly finding new ways to abuse the protocols we trust, and OAuth is no exception. The same flexibility that makes OAuth powerful also makes it a target.

For organizations using Microsoft Entra ID, the takeaway is clear: you can’t rely on default logging alone. You need to understand the full range of OAuth flows in your environment, and you need tooling that can detect anomalies in those flows, not just in sign-in events.

As for the threat actors behind this campaign, researchers are still tracking them. But the fact that at least two distinct groups have adopted the technique suggests it’s not a one-off. It’s a playbook, and it’s likely to spread.

The best defense is awareness — and a healthy skepticism about what your logs are actually telling you. Because sometimes, the absence of an alert is the alert.

Why AI Security Decisions Need a Reality Check

AI security agents are no longer just chatty assistants. They’re making actual calls — triaging alerts, prioritizing fixes, even suggesting remediation steps. That’s a big leap from the days when automation stopped at log correlation.

But here’s the problem: most of these agents lean on fragmented signals. Scanner output, severity scores, threat intel, config findings, exposure data. Each one tells a piece of the story, and none of them tells the whole story.

Attackers don’t move through an environment one neat step at a time. They chain exploits, pivot laterally, and exploit gaps between tools. If your AI is making decisions based on siloed data, it’s making decisions in the dark.

What Pentera Does Differently

Pentera has built a platform that treats AI security workflows as something to be tested, not just trusted. Instead of letting agents run on assumptions, Pentera continuously validates them against real attack simulations.

The idea is simple: if an AI agent recommends a remediation, you should know whether that recommendation actually holds up under attack. Pentera’s validation engine does exactly that — it runs safe, controlled exploits against your environment to see if the AI’s decisions would survive contact with a real adversary.

From Signal to Proof

Most security tools give you signals. Pentera wants to give you proof. It takes the AI’s output — the priorities, the suggested actions — and stress-tests them. Did the agent miss a critical path? Did it over-prioritize a low-risk issue? The validation engine surfaces those gaps.

This isn’t theoretical. Pentera’s approach mirrors how penetration testers work, but at machine speed and scale. It’s continuous, not a once-a-year exercise.

The Fragmentation Trap in Modern Security Stacks

Let’s be honest: the average enterprise runs dozens of security tools. Each one generates its own alerts, scores, and dashboards. AI agents are supposed to unify this chaos, but they often just aggregate it.

Aggregation isn’t validation. Just because an AI can summarize findings from five tools doesn’t mean its conclusions are correct. In fact, the more data you feed a model, the more confident it can be — and confidence isn’t accuracy.

Pentera’s pitch is that validation closes this loop. You don’t just ask the AI what to do; you test whether doing it actually works.

How Validation Changes the AI Security Game

When you validate AI decisions against simulated attacks, a few things happen:

• False confidence drops — agents that look good on paper get exposed quickly.
• Priorities shift — remediation efforts focus on what actually matters, not what’s loudest.
• Trust grows — security teams are more likely to act on AI recommendations they’ve seen verified.

That last point is huge. The biggest barrier to AI adoption in security isn’t model quality; it’s trust. Teams won’t let an agent touch production if they can’t verify its judgment.

What This Means for Security Teams

For practitioners, the takeaway is straightforward: start treating AI outputs like hypotheses, not facts. Test them. Pentera’s validation engine is one way to do that, but the mindset matters more than any single tool.

Ask yourself: when your AI flags a critical vulnerability, do you know it’s critical? Or just that it has a high CVSS score? Validation gives you the answer.

It’s also worth considering how this fits into broader automation. If you’re building automated security response workflows, validation should be a checkpoint, not an afterthought. The same logic applies to AI-driven threat prioritization — you need to know the logic holds.

Pentera’s bet is that the future of AI security isn’t smarter models alone. It’s models that are held accountable. That’s a bet worth watching.

SilverFox’s New Tactic: A Three-Driver Assault

The Chinese-speaking cybercrime crew known as SilverFox has shifted gears. Instead of relying on a single vulnerable driver, they’re now chaining three different ones in a bring your own vulnerable driver (BYOVD) attack. The target? A Japanese organization in the industrial manufacturing sector. The goal? Dropping ValleyRAT (also tracked as Winos 4.0) for persistent remote access.

This isn’t just another malware campaign. It’s a deliberate evolution in technique, combining newly observed vulnerable-driver abuse with abuse of legitimate software—a mix that makes detection significantly harder.

How the BYOVD Chain Works

In this campaign, SilverFox leverages a trio of drivers to bypass security controls. Each driver serves a specific purpose: one to disable or tamper with endpoint protection, another to gain kernel-level privileges, and a third to maintain stealth. The chain is designed to work in sequence, with each step paving the way for the next.

• Driver 1: Disables security software (anti-virus, EDR).
• Driver 2: Elevates privileges to kernel mode.
• Driver 3: Provides persistence or hides malicious activity.

Once the drivers do their job, the attackers drop ValleyRAT—a remote access trojan that gives them full control over the infected machine. ValleyRAT isn’t new, but its delivery via a three-driver BYOVD chain is a notable escalation.

Why Target a Japanese Manufacturer?

Industrial manufacturing is a high-value target. These organizations often run legacy systems, have high uptime requirements, and can’t afford downtime for security patches. That makes them attractive to cybercriminals seeking long-term access for data theft, ransomware staging, or industrial espionage.

SilverFox has a history of targeting East Asian entities, but this specific focus on a Japanese manufacturer suggests either a strategic shift or a tailored operation. The use of ValleyRAT—a tool commonly associated with Chinese-speaking threat actors—reinforces the group’s profile.

BYOVD Attacks: A Growing Trend

BYOVD attacks aren’t new, but they’re becoming more common. The technique exploits signed, legitimate drivers that have known vulnerabilities. Attackers load these drivers to perform privileged operations that would otherwise be blocked.

What’s concerning here is the multi-driver approach. Most BYOVD attacks use a single driver. Chaining three suggests a more sophisticated operation, likely with custom tooling or at least careful planning. It also complicates mitigation—blocking one driver isn’t enough if two others can still be abused.

Defending Against Multi-Driver BYOVD

For defenders, the key is layered protection. Relying on a single security control is no longer viable. Here are some practical steps:

• Maintain an up-to-date blocklist of known vulnerable drivers.
• Use memory integrity and virtualization-based security (VBS) to prevent driver loading.
• Monitor for unusual driver load events in your SIEM.
• Segment networks to limit lateral movement post-compromise.

These measures won’t stop every attack, but they raise the bar significantly.

ValleyRAT: More Than Just a Backdoor

ValleyRAT, also known as Winos 4.0, is a feature-rich trojan. It supports keylogging, screen capture, file exfiltration, and command execution. In this campaign, it’s used for persistent remote access—meaning the attackers can return anytime they want.

The malware is often delivered via phishing emails or exploit kits, but the BYOVD chain here adds a layer of sophistication. It’s a reminder that even known malware can be dangerous when paired with novel delivery mechanisms.

What This Means for Industrial Security Teams

If you’re in manufacturing, this is a wake-up call. The attackers aren’t just targeting IT systems; they’re after operational technology (OT) and intellectual property. A successful breach could mean stolen designs, disrupted production, or worse.

Security teams should review their driver policies, audit existing allowlists, and ensure that endpoint protection is configured to detect anomalous driver behavior. Regular threat hunting for ValleyRAT indicators is also advisable.

For more on related threats, check out our analysis of ValleyRAT malware delivery methods and BYOVD attack mitigation strategies.

Final Thoughts

SilverFox’s three-driver BYOVD chain is a clear signal: cybercriminals are getting more creative with their toolkits. The attack on the Japanese manufacturer shows that no sector is off-limits, and no single defense is sufficient.

Staying ahead requires vigilance, continuous monitoring, and a willingness to adapt. The threat landscape is evolving—are your defenses keeping pace?