Fifteen vulnerabilities in a widely deployed SMB networking stack chain together through the one flow that should be trustworthy — zero-touch provisioning. That is today’s lead story, and it is a reminder that automating device onboarding without authenticating the devices is automating your own compromise. Alongside it: Talos publishes the first large-scale, data-driven look at how adversaries are actually using commercial AI tools to write malware, and researchers quantify the scope of a decades-old BMC flaw that leaks authentication hashes before login on 24,000 servers.

In the News

Forescout researchers disclosed 15 vulnerabilities across TP-Link’s Omada SDN ecosystem — spanning the software controller, access points, routers, and switches. The critical finding is not any single flaw in isolation but the chain: an attacker who can reach the provisioning network can abuse the zero-touch provisioning (ZTP) flow to inject malicious configurations, pivot to the Omada controller, and ultimately take over the entire network infrastructure.

The root cause is a familiar pattern in network provisioning security: devices trust configuration payloads during onboarding without authenticating the source. This means the provisioning channel itself becomes the attack surface. For mid-market and SMB networks where TP-Link Omada is widely deployed, this is a particularly dangerous exposure because these environments often lack the management-plane segmentation that would contain the blast radius.

The chain covers multiple MITRE ATT&CK techniques: initial access via trusted provisioning flows (T1195.002 — Supply Chain Compromise: Compromise Software Supply Chain, adapted to infrastructure provisioning), lateral movement to the controller, and persistence through configuration modification. Defenders should verify that management-plane traffic is segmented from the data plane, that provisioning flows require mutual authentication, and that controller access is restricted to jump hosts with MFA.

What defenders should do: Segment BMC and device provisioning networks from production. Require mutual authentication during device onboarding. Restrict Omada controller access to dedicated management VLANs with ACLs. Monitor for unexpected devices appearing on provisioning networks.

Talos Analyzes AI-Generated Malware — Prompt Logs from Real Attacker Endpoints

Cisco Talos published a data-driven analysis of how adversaries are weaponizing commercial AI tools, based on prompt logs recovered from actual threat actor endpoints. The tools in use included Claude, Cursor, CodeX, and Gemini. The research found that AI safety guardrails failed the majority of the time, and that the operational impact breaks along skill lines: novice actors produced functional but limited malware, while experienced operators used AI to build sophisticated, production-quality tooling.

This is the first large-scale analysis backed by real attacker data rather than theoretical demonstrations. It moves the conversation from “could AI be used for attacks” to “here is how it is being used, how often guardrails fail, and what the output looks like.” The defensive implication is that signature-based detection alone is insufficient against AI-generated code because each output is syntactically unique. Behavioral detection — keying on what code does rather than what it looks like — is the primary countermeasure.

What defenders should do: Prioritize behavioral endpoint detection over signature-matching. Monitor DNS for novel C2 domains generated by AI-assisted tooling. Use the Talos research as justification for AI governance policies that include visibility into which AI services are reachable from corporate endpoints.

24,000 BMC Servers Leak Authentication Hashes Before Login

Researchers quantified the internet exposure of a decades-old design flaw in baseboard management controller implementations: over 24,000 internet-facing BMC interfaces disclose authentication hashes to unauthenticated requesters via the IPMI protocol. An attacker who captures these hashes can crack them offline and gain full out-of-band control of the server — including power management, BIOS reconfiguration, virtual media mounting, and OS-level access through the KVM interface.

BMC compromise is particularly dangerous because it operates below the operating system. An attacker with BMC access can reinstall the OS, modify firmware, or monitor all console output without any visibility to endpoint detection tools running inside the OS. The flaw has existed for years, but the newly published scan data puts a number on the exposure: 24,000 servers that should never have been reachable from the internet.

What defenders should do: Audit whether any BMC/IPMI interfaces are internet-facing — they should never be. Restrict BMC access to a dedicated out-of-band management VLAN accessible only from jump hosts. Change default IPMI credentials and disable IPMI-over-LAN where the feature is not operationally required.

DOUBLECUP Loader Hides Malware in Browser-Cached PNG Images

A new Russian loader-as-a-service called DOUBLECUP uses steganography to embed malware inside PNG images that are cached by the victim’s browser. The delivery chain begins with ClickFix social engineering lures that direct users to attacker-controlled pages. The pages serve benign-looking PNG images that the browser caches normally. Embedded within those images are encoded payloads — CountLoader and DeviceManager RAT — that extract and execute after the initial social engineering interaction.

The technique is notable because the payload never appears as an executable in network transit. URL reputation checks see a legitimate image request. File-type inspection sees a valid PNG. The malicious content only activates after the steganographic extraction step runs locally. Both Windows and macOS are targeted. This represents MITRE ATT&CK T1027.003 (Obfuscated Files or Information: Steganography) combined with T1204.001 (User Execution: Malicious Link).

What defenders should do: Deploy DNS-layer controls that catch the C2 callback regardless of delivery mechanism. Evaluate browser isolation to prevent cached content from executing in the local browser context. Monitor for ClickFix-pattern social engineering in user-reported phishing.

Today’s Deep Dive — Pass-ta-key: When Passkeys Become Single-Factor

Researchers disclosed three attack paths that allow malware running on a compromised Windows device to hijack passkeys synced through Google Password Manager — bypassing user verification and extracting private key material. The attacks, collectively named “pass-ta-key,” target the implementation layer between the FIDO2 specification and Google’s synced credential storage.

The core issue: Google Password Manager’s synced passkeys store private keys protected by the device’s screen lock or biometric. But on a compromised Windows endpoint, malware with local admin or SYSTEM-level access can bypass the Windows Hello user verification prompt and access the credential store directly. The three attack paths vary in sophistication, but all achieve the same outcome — the attacker obtains a passkey that was intended to be a phishing-resistant, device-bound credential.

This matters because passkeys are being positioned across the industry as a replacement for passwords and traditional MFA. The FIDO2 specification itself remains sound — the vulnerability is in how synced passkeys are implemented and stored at the platform level. Hardware-bound passkeys (FIDO2 security keys where the private key never leaves the hardware token) are not affected. The distinction between synced passkeys and hardware-bound passkeys is operationally critical: synced passkeys trade the unphishability of FIDO2 for convenience, and that trade introduces a new attack surface when the sync target is a compromised device.

Detection for pass-ta-key exploitation is difficult because the malware uses legitimate OS APIs to access the credential store. The primary detection signal is the presence of the initial compromise — the malware that enables the passkey theft. EDR behavioral monitoring for unexpected access to Chrome credential storage paths and Windows Credential Manager APIs is the highest-fidelity indicator available. MITRE ATT&CK mapping: T1555.003 (Credentials from Password Stores: Credentials from Web Browsers), T1556 (Modify Authentication Process).

Primary mitigation: For high-security environments, deploy hardware-bound FIDO2 keys (YubiKey, Titan) where private keys cannot be extracted. For environments using synced passkeys, ensure endpoint security controls detect and prevent local privilege escalation — that is the prerequisite for all three attack paths.

Detection Spotlight

Monitor for unexpected access to Chrome’s credential storage on Windows, which is the precursor to pass-ta-key exploitation. The following Splunk SPL query detects non-browser processes accessing Chrome’s Login Data and Local State files:

index=edr sourcetype=sysmon EventCode=11
(TargetFilename="*\\Google\\Chrome\\User Data\\*\\Login Data"
 OR TargetFilename="*\\Google\\Chrome\\User Data\\Local State")
NOT (Image="*\\chrome.exe" OR Image="*\\Google\\Chrome\\Application\\*")
| stats count by Image, TargetFilename, Computer, _time
| where count > 0
| sort -_time

This catches non-Chrome processes touching credential storage files. Expect false positives from legitimate backup software and enterprise browser management tools — baseline those and exclude by Image path. True positives indicate credential theft tooling or infostealer activity and warrant immediate investigation.

References

Subscribe to the it-learn Brief

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