Managed Defense Threat Insights: May 2026 Newsletter

Cyber Defense Center – Highlights

Executive Snapshot

SecurityHQ’s Cyber Defense Team observed two major abuse patterns: OAuth Device Code Flow abuse and Direct Send email spoofing abuse. Both involve attackers misusing legitimate Microsoft features to bypass traditional controls. The first targets identity and cloud access, while the second targets email trust and user panic through spoofed ransom emails. Overall, both cases highlights the need for stronger Conditional Access, OAuth governance, mail flow restrictions, and email authentication controls.

Increase in OAuth Device Code Flow Abuse Incidents

Detection: A number of incidents were raised where users received emails asking them to click on a code, followed by login activity from unexpected locations. SecurityHQ SOC team detected this behaviour based on Microsoft Entra ID logs where the protocol type was “DeviceCode” and the resource name was “Microsoft Graph”. The below graph illustrates the rise in incidents related to OAuth Device Code–based compromise activity.

Description: OAuth Device Code Flow is a legitimate authentication mechanism designed for devices with limited input capabilities, such as smart TVs, printers, or IoT devices. During the authentication process, users are prompted to visit a legitimate login page and enter a device code to complete authentication.

Threat actors abuse this flow by generating valid device codes and socially engineering users into entering them on trusted authentication portals. Once the victim completes the authentication, the attacker receives access tokens that can be used to access cloud services, emails, files, or other organizational resources without requiring the victim’s password directly.

Recommendations:

• Block OAuth Device Code Flow authentication for the tenant or restrict it to compliant devices only via Conditional Access Policy
• Review OAuth application permissions and remove unauthorized or suspicious applications.
• Implement Conditional Access Policies to restrict authentication from risky locations, devices, or identities.

Direct Send Feature Abuse for Spoofed Ransom Emails

Detection : SOC identified the incident through monitoring of suspicious email activity and mail flow anomalies within the organization’s email infrastructure. Alerts were triggered after detecting spoofed emails originating from external IP addresses while impersonating internal company domains.

Description: Direct Send is a legitimate email delivery method in Microsoft Exchange environments that allows devices, applications, or printers to send emails directly to internal recipients without authentication.

Threat actors abuse misconfigured Direct Send connectors or exposed mail servers to send spoofed emails that appear to originate from trusted internal domains. These emails contains:

• Fake claims of mailbox or device compromise
• Generic user browsing trends
• Threats of data leakage or exposure
• Demands for cryptocurrency payments
• Social engineering content intended to create panic and urgency

Since these emails may originate from legitimate mail infrastructure and use trusted domains, they bypass basic spam filtering and appear authentic to end users.

Recommendations:

• Restrict Direct Send functionality only to authorized internal systems and trusted IP addresses.
• Disable unused SMTP relay connectors and review mail flow configurations regularly.
• Implement and enforce SPF, DKIM, and DMARC policies to reduce email spoofing risks.
• Regularly audit email infrastructure configurations and review exposed mail services.

---

Threat Detection Engineering

Threat Insights – May 2026

Advancing Threat Detection Engineering for AI Security

What’s New This Release

New Detections – Detailed Breakdown

Overview

This detection identifies potential Cross-Prompt Injection Attack (XPIA) attempts, where malicious instructions are embedded within external content that is consumed by AI systems, Copilots, or agentic workflows. The attack is particularly insidious because the AI itself becomes an unwitting vehicle – processing attacker-controlled content as if it were a legitimate instruction.

Overview

This detection identifies Copilot prompts that are flagged as potential jailbreak attempts — where a user may be trying to bypass safety controls, override system instructions, or manipulate the AI into producing restricted or harmful responses. Jailbreaks can be subtle, using adversarial phrasing, roleplay scenarios, encoded instructions, or multi-turn manipulation.

“Getting Your AI Systems Monitored: What the SOC Needs From You”

1. Log Sources & Telemetry The SOC requires prompt-level audit logs from your AI platform, identity and authentication logs, data access logs showing what the AI retrieved or acted on, API/integration logs for agentic workflows, and network egress logs to detect potential data exfiltration. Without these forwarding to the SIEM, detection coverage cannot be established.

2. Identity & User Context Every AI interaction must be attributable to a verified user – UPN, role, department, and MFA status are the baseline. Service accounts used by AI agents must be separately inventoried. Alerts without clear user identity cannot be meaningfully investigated or escalated.

3. AI System Inventory & Scope Documentation Provide a registry of all AI tools in use, the data sources each system can access, active plugins or connectors, and a description of what normal usage looks like for your deployment. This context is what allows the SOC to distinguish legitimate behavior from an attack.

4. Operational Requirements A named platform owner must be reachable for alert validation. Logs must be retained for a minimum of 90 days. The SOC must be notified when new integrations or capabilities are added. Legal and privacy teams should sign off on prompt content review as part of your AI monitoring policy.

Readiness Checklist Before requesting SOC onboarding for your AI system, confirm: audit logging is active and forwarding prompt-level telemetry, user identity is captured per session, accessible data sources are documented, and a platform owner is named. Teams that meet all four can engage the Threat Detection Engineering team to initiate coverage.

---

Threat Management

Three Zero-Days, One Trusted Tool: Neutralising the Defender Exploit Chain

SecurityHQ’s Threat Management Team uncovered attackers abusing Microsoft Defender to gain full SYSTEM-level control over protected endpoints. By deploying bespoke detections before Microsoft released patches, we ensured zero impact across all managed tenants.

Threat Snapshot

Defender operates as one of the most privileged processes on a Windows endpoint and that trust is precisely what is being abused. The attacker plants a file Defender is designed to clean up, then hijacks that clean-up step and redirects it to overwrite a protected system file, inheriting Defender’s SYSTEM-level rights in the process. A second technique disables Defender’s updates so its protection degrades unnoticed. The three exploits, named by the researcher who disclosed them, are:

How the exploit works

BlueHammer and RedSun share a single mechanical core: they win a race against Defender’s privileged file operation and redirect it. Mapping that sequence is what allowed us to build detection before a patch was available:

Our Response

With working exploits public ahead of any fix, signature-based protection alone left a gap. We focused on the behaviour Defender’s own trusted processes being coerced into anomalous privileged writes and pushed four custom analytics live across every managed MDE tenant:

---

Threat Hunting

Hunting for CVE-2026-31431 (Copy Fail): Linux Kernel Local Privilege Escalation via Page-Cache Corruption

Hypothesis

SecurityHQ’s Threat Hunting team investigated whether adversaries had obtained initial local access to managed Linux hosts, via compromised SSH credentials, exposed services, malicious container images, or CI/CD runner compromise and subsequently leveraged the Copy Fail exploit to escalate to root. The assumption: an attacker with any authenticated local foothold could silently modify kernel page-cache memory to flip their UID to 0 in /etc/passwd, invoke su with their legitimate password, and obtain a root shell, all without writing any persistent artifact to disk, and without triggering traditional file-integrity-based detections.

How the Exploit Chain Works

Copy Fail does not require a network-facing vulnerability, elevated privileges, kernel modules, or special capabilities. It operates entirely from an authenticated local foothold through the following steps:

1. Initial Access: The attacker holds any authenticated local execution like compromised SSH session, exposed shell service, malicious container image, or CI/CD runner job.
2. Vulnerable Copy Path: The attacker opens an AF_ALG socket using the authencesn(hmac(sha256),cbc(aes)) algorithm. A crafted sendmsg() sequence passes 8 bytes of attacker-controlled AAD data with the PWND sentinel marker, then splice() moves a page-cache-backed file into the AF_ALG op socket.
3. Page-Cache Corruption: recv() drives decryption. The authentication check fails (EBADMSG) but the in place scratch write fires regardless, landing 4 bytes of attacker-controlled data into the kernel’s cached view of any world-readable file without touching disk.
4. Root Escalation: The exploit targets the user’s UID field in /etc/passwd (e.g. “1000” → “0000”). libc and PAM now report the user as UID 0. Calling su with the user’s own valid password results in a root shell. /etc/shadow is never touched; the change is in-memory only and clears on reboot.

What We Found

Exposure Signals: Kernel version audits across managed Linux fleets identified hosts running unpatched kernels in the affected range. Exposure was highest across:

• Kubernetes worker nodes running Ubuntu 24.04 LTS and Amazon Linux 2023
• CI/CD runner pools on shared Linux VMs not configured for live patch deployment.
• Multi-tenant shared jump hosts and shell servers with broad SSH access

Behavioural Hunt Findings: Our hunts surfaced the following behavioural signals across endpoint telemetry and audit log sources:

• Short-lived Python 3 processes executed from /tmp, /dev/shm directories.
• Container monitoring, application readiness checks, and routine container management activities observed across the environment were assessed as legitimate operational behaviour, with no indicators of malicious container activity or container escape behaviour identified during the investigation.

Privilege Escalation Indicators: On multiple hosts, further investigation surfaced post-escalation signals:

• UID 0 process transitions from low-privileged service accounts without sudo, PAM policy, or setuid workflow confirmed via auditd records.

What We Did Not Found

Despite confirming exposure and exploit staging artifacts on several hosts, investigation on the majority of flagged systems found:

• No evidence of persistent post-exploitation activity (no new cron jobs, systemd timers, added authorized keys, or suspicious binaries in writable paths)
• No evidence of lateral movement from affected hosts toward adjacent Kubernetes control planes or cluster services
• No data exfiltration detected from hosts where escalation artifacts were found & containment actions were taken prior to any confirmed impact

This is consistent with the non-persistent nature of the Copy Fail exploit: the page-cache modification clears on reboot, and the exploit itself is silent to file-integrity monitoring and most SIEM rules focused on disk writes.

Why This Hunt Matters

Copy Fail represents a class of vulnerability that bypasses most conventional detection postures. The exploit operates entirely in kernel memory, writes no persistent artifact to disk, generates no network callback during privilege escalation, and clears on reboot leaving a narrow forensic window.

Critically, the availability of a working 732-byte pure-Python exploit, deployable in a single curl-pipe command from any public URL, means the barrier to exploitation is minimal. Any attacker with a foothold from a compromised cloud workload to an insider can reliably escalate to root on an unpatched system in seconds.

Key Takeaways

• CVE-2026-31431 is patch-and-reboot critical. Applying kernel updates without rebooting leaves hosts fully exposed. Verify the loaded kernel with uname -r after every patch cycle.
• Treat the disclosure-to-patch window as an active exposure period. Audit for privilege escalation activity on any host that ran an affected kernel.
• AF_ALG socket usage from non-root processes is anomalous. It has almost no legitimate application in standard enterprise Linux environments; flag and investigate any instance.
• Page-cache corruption is forensically silent on disk. Standard file integrity monitoring will not detect Copy Fail. Detection requires runtime or syscall-level behavioural telemetry.
• Kubernetes worker nodes, CI/CD runners, and shared jump hosts are the highest-risk targets. Blast radius on these platforms is disproportionate, a single exploit can expose cloud credentials, signing keys, cluster service account tokens, and workloads from multiple tenants.
• Credential rotation is mandatory for any host that ran an unpatched kernel. Assume any secrets accessible from the host during the exposure window are compromised.

---