CISA’s 48-hour remediation mandate for an actively exploited Drupal SQL injection flaw sets the tone for a busy Monday. Alongside, Dutch law enforcement executed one of 2026’s largest infrastructure takedowns against Russian-linked bulletproof hosting, and Iranian Nimbus Manticore is running phishing and SEO poisoning campaigns against aviation and software targets. The FBI also issued a warning about a phishing-as-a-service platform that bypasses MFA entirely using OAuth device code flow abuse.

In the News

CISA Mandates 48-Hour Patch for Actively Exploited Drupal SQL Injection

CISA added an actively exploited SQL injection vulnerability in Drupal CMS to the Known Exploited Vulnerabilities (KEV) catalog and set a 48-hour remediation deadline for federal agencies. The flaw allows unauthenticated remote attackers to execute arbitrary SQL queries against Drupal’s database backend — no credentials, no session, no prior access required.

The 48-hour timeline is aggressive but reflects the severity: unauthenticated SQL injection against a CMS platform with a massive internet-facing footprint is a textbook initial access vector. Attackers can extract credentials, modify content, or pivot to the underlying database server depending on the database user’s privilege level.

For any organization running Drupal — particularly internet-facing instances — this is not a “next patch cycle” issue. The active exploitation status means attackers are already scanning for and exploiting vulnerable instances. Web application firewalls with SQL injection detection rules provide a compensating control while patching is underway, but the patch is the fix.

What defenders should do: Identify all Drupal instances (including forgotten dev and staging environments), apply the security update immediately, and verify WAF rules are active for SQL injection patterns against Drupal endpoints. Check access logs for anomalous POST requests to Drupal’s form and API endpoints — SQL injection payloads in POST bodies are common for this class of flaw.

Netherlands Seizes 800 Bulletproof Hosting Servers Tied to Russian Cyber Operations

Dutch law enforcement seized approximately 800 servers and arrested two operators of a bulletproof hosting network connected to Russian cyber operations. The infrastructure had direct ties to entities under Stark Industries sanctions and had been used to host command-and-control servers, stage attacks, and proxy malicious traffic for multiple threat actor groups operating out of Russia.

Bulletproof hosting remains one of the most enabling pieces of adversary infrastructure. These providers explicitly market their willingness to ignore abuse complaints, making them the preferred hosting layer for C2 servers, phishing pages, malware delivery infrastructure, and data exfiltration drop points. Taking 800 servers offline in a single operation disrupts active campaigns across multiple threat actor groups simultaneously.

The operational significance extends beyond the immediate takedown. Seized servers yield intelligence — logs, customer records, payment trails — that frequently enables follow-on investigations and attribution. For defenders, the takedown will cause short-term disruption to active campaigns, but bulletproof hosting is a commoditized market and operators will relocate.

What defenders should do: Review threat intelligence feeds for updated indicators from the seized infrastructure. Monitor netflow and DNS logs for connections to ASNs associated with Stark Industries and known bulletproof hosting providers. Network detection tools that flag traffic to newly relocated C2 infrastructure based on behavioral patterns (beaconing intervals, JA3/JA4 fingerprints) provide more durable detection than IP-based blocklists alone.

Iranian Nimbus Manticore Deploys MiniFast and MiniJunk V2 via Phishing and SEO Poisoning

Iranian threat group Nimbus Manticore is running active campaigns against aviation and software organizations across the U.S., EU, and Middle East. The group deploys two malware families — MiniFast and MiniJunk V2 — through dual delivery vectors: traditional spearphishing with themed lure documents and SEO poisoning that directs victims to attacker-controlled download pages.

The SEO poisoning vector is the more operationally significant one. It bypasses email security entirely. Victims discover the malicious page through a legitimate search engine query — typically related to aviation procurement documents or software licensing — and download what appears to be a legitimate file. The page ranks because the threat actor has invested in SEO manipulation: backlink farms, keyword stuffing on compromised sites, and domain age simulation.

The timing is notable. Post-U.S.-Israel strike activity has historically correlated with Iranian retaliatory cyber operations, and the sector targeting — aviation and defense-adjacent software — fits that pattern. MITRE ATT&CK techniques include Phishing (T1566), Drive-by Compromise via SEO poisoning (T1189), and Command and Control via standard application layer protocols (T1071).

What defenders should do: Secure web gateways and DNS filtering should flag downloads from newly registered or low-reputation domains. Endpoint detection should have behavioral coverage for loader-class malware (process injection, DLL sideloading). Aviation and software sector organizations should brief users on the specific lure themes in circulation.

FBI Warns of Kali365 PhaaS Platform Abusing Microsoft 365 OAuth Device Code Flow

The FBI issued a public warning about Kali365, a phishing-as-a-service (PhaaS) platform that exploits the Microsoft 365 OAuth device code authorization flow to bypass multi-factor authentication and hijack user sessions. The technique is elegant in its simplicity: the attacker generates a device code, social-engineers the victim into entering it on the legitimate Microsoft login page, and the victim’s own MFA authentication grants the attacker a valid session token.

This is a critical distinction from traditional credential phishing. The victim never enters credentials on a fake page. They authenticate on the real Microsoft login page, satisfy MFA, and unknowingly grant the attacker a session token. Traditional phishing detection — URL reputation, page similarity analysis — does not catch this because the login page is genuine.

The device code flow was designed for devices without browsers (IoT devices, smart TVs), but it is enabled by default in most Microsoft 365 tenants. The primary mitigation is disabling the device code flow via conditional access policies for all users and applications that do not require it. FIDO2/phishing-resistant MFA does not directly prevent this technique because the user is authenticating on the real page — the attack vector is the authorization grant, not credential interception.

What defenders should do: Audit conditional access policies to disable the device code flow for all users except explicitly required device scenarios. Monitor Azure AD sign-in logs for deviceCode authentication events, particularly from unusual IP addresses or geographic locations. CASB tools should flag anomalous OAuth token grants that occur shortly after device code authentication events.

Today’s Deep Dive — OAuth Device Code Flow Abuse: The MFA Bypass That Uses the Real Login Page

The Kali365 FBI warning highlights a technique that deserves deeper examination because it undermines a core assumption in identity security: that MFA makes credential phishing ineffective.

How Device Code Flow Works (Legitimately)

The OAuth 2.0 device authorization grant (RFC 8628) was designed for input-constrained devices. The flow works in five steps:

  1. The device (or attacker) requests a device code from the authorization server (Microsoft’s token endpoint).
  2. The authorization server returns a device code, a user code, and a verification URL (https://microsoft.com/devicelogin).
  3. The user navigates to the verification URL on a separate device, enters the user code, and authenticates — including MFA.
  4. The authorization server issues an access token and refresh token to the requesting device.
  5. The device now has authenticated access to the user’s resources.

How Attackers Abuse It

The attacker substitutes themselves for the “input-constrained device” in step 1. The social engineering is typically a phishing email or message that says “enter this code to verify your account” or “complete this security check.” The victim sees a real Microsoft login page, enters the code, completes MFA, and the attacker receives the session tokens.

MITRE ATT&CK maps this to Steal Application Access Token (T1528) and Phishing (T1566.002 — spearphishing link). The key insight is that T1528 occurs after successful MFA — it is a post-authentication token theft, not a credential theft.

Detection

The primary detection signal is the deviceCode grant type in Azure AD sign-in logs. Most organizations have near-zero legitimate device code authentication events. Any deviceCode event from an unexpected IP, user, or time window is a high-fidelity indicator.

SigninLogs
| where AuthenticationProtocol == "deviceCode"
| where ResultType == 0
| project TimeGenerated, UserPrincipalName, IPAddress, Location, AppDisplayName, DeviceDetail
| where IPAddress !in ("known_legitimate_device_IPs")

False positive rate is low in environments that have not explicitly deployed device-code-dependent applications. If your organization does not use smart TVs or IoT devices that authenticate to Microsoft 365, any successful device code sign-in is suspicious.

Primary Mitigations

  1. Disable device code flow via conditional access policy for all users except those with explicitly documented need (specific IoT or kiosk scenarios).
  2. Monitor for deviceCode grant type in Azure AD sign-in logs — alert on any successful authentication using this flow.
  3. Enforce token binding where available — Device Bound Session Credentials (DBSC) in Chrome 146+ render stolen tokens unusable on a different device.
  4. User awareness — brief users that Microsoft will never ask them to enter a device code via email. The social engineering component is the weakest link.

The uncomfortable reality is that phishing-resistant MFA (FIDO2) does not fully prevent this attack. FIDO2 prevents credential interception — but in device code flow abuse, the user is authenticating on the real page with their real credentials. The defense is architectural: disable the flow, monitor the logs, and reduce the token’s portability.

Detection Spotlight

This week’s detection targets OAuth device code authentication events in Azure AD — directly relevant to the Kali365 FBI warning.

// Detect successful OAuth device code authentications
// Low false-positive rate in environments without IoT/kiosk Microsoft 365 usage
// Triage: verify whether the authenticating user has a documented device-code use case
SigninLogs
| where TimeGenerated > ago(7d)
| where AuthenticationProtocol == "deviceCode"
| where ResultType == 0  // Successful sign-in only
| summarize
    Count = count(),
    FirstSeen = min(TimeGenerated),
    LastSeen = max(TimeGenerated),
    IPs = make_set(IPAddress),
    Apps = make_set(AppDisplayName)
    by UserPrincipalName
| sort by Count desc

Run this against your Azure AD sign-in logs. In most enterprise environments, legitimate device code authentication is rare. Any hits warrant immediate investigation — verify whether the user intentionally authenticated a device, check the source IP against known office and VPN ranges, and determine whether the application is sanctioned.

References

Subscribe to the it-learn Brief

Get the daily cybersecurity brief in your inbox every weekday morning — news, SE angles, and detection queries.