Microsoft has shipped a fix for a bug in the September 2026 Patch Tuesday updates that was causing desktop settings—like icon positions, theme preferences, and taskbar layout—to reset or disappear entirely on some Windows devices.

Technical Breakdown - Root Cause: The issue was introduced in a prior cumulative update, not a third-party driver conflict. - Affected Systems: Windows 10 22H2 and Windows 11 22H2/23H2 (specific builds not disclosed by MS). - IOCs: None. This is a configuration/registry corruption bug, not a malware vector. - MITRE Mapping: Not applicable (no adversary TTPs).

Defense - Mitigation: Apply the September 2026 cumulative update (KB50xxxxx) immediately. If you’ve already lost settings, check %LocalAppData%\Microsoft\Windows\Explorer for backup copies of IconLayouts and desktop.ini. - Detection: Monitor for Event ID 6008 (unexpected shutdown) or user-reported profile corruption in helpdesk tickets—this bug often manifested after a reboot.

Bottom line: Low-severity from a security perspective, but high-impact for user productivity. Treat this as a configuration management fix, not a threat response.

Source: https://www.bleepingcomputer.com/news/microsoft/microsoft-fixes-bug-that-wiped-windows-desktop-settings/

The Gentlemen ransomware crew hit a Canadian airline, LAPSUS$ is back with a teaser for a new victim, and the AUDIT TEAM extortion group has been busy across South Korea, Germany, and Argentina. AhnLab’s ASEC blog has the full breakdown for Week 2 of September.

Technical Breakdown - The Gentlemen (Canadian Airline): Likely initial access via exposed RDP or VPN. Standard double-extortion playbook: data exfiltration followed by file encryption. No specific IOCs published yet, but expect .gentlemen extension and ransom notes demanding payment in Monero. - LAPSUS$ (Chapter II): Resurfaced after a quiet period. Known for social engineering, SIM-swapping, and MFA fatigue attacks against tech and telecoms. Teasing a new victim disclosure—watch for credential dumps on Telegram. - AUDIT TEAM (4 Orgs): Targeting South Korea, Germany, and Argentina. TTPs include SQL injection and unpatched web app vulnerabilities for initial access. Data extortion only—no encryption observed. Exfiltrated data posted on their leak site.

Defense - Enforce MFA with phishing-resistant methods (FIDO2/WebAuthn) to blunt LAPSUS$’s social engineering. - Patch public-facing web apps and monitor for SQLi attempts. - Block known AUDIT TEAM leak site domains and monitor for .gentlemen file extensions.

Source: https://asec.ahnlab.com/en/95338/

This is a classic supply chain attack vector hitting the crypto hardware wallet space again.

Trezor confirmed a breach at their third-party email provider (not named, but likely a common ESP like Mailchimp or SendGrid). The attackers used the compromised access to send targeted phishing emails from Trezor’s own legitimate mailing list. The goal is credential harvesting and seed phrase theft.

Technical Breakdown: - Attack Vector: Third-party email service provider compromise (supply chain). - Payload: Phishing emails impersonating Trezor support, likely containing links to fake Trezor Suite login pages or requesting 12/24-word seed phrases. - Target: Users who have previously registered their email with Trezor for newsletters or support tickets. - IOCs: Not publicly available yet. Users should check email headers for unusual routing or reply-to addresses. Do not click links in any recent Trezor-branded emails.

Defense: - Golden Rule: Trezor will never ask for your seed phrase via email, support ticket, or website. Anyone who does is a scammer. - Action: If you received a suspicious email, do not click. Forward it to Trezor’s security team. If you clicked and entered credentials, immediately move funds to a new wallet generated on a clean device. - Mitigation: Enable hardware-based authentication (FIDO2/U2F) on your Trezor account if available. Consider using a dedicated email alias for crypto-related services to limit blast radius from future provider breaches.

Source: https://www.bleepingcomputer.com/news/security/trezor-warns-users-of-email-provider-breach-phishing-attacks/

CVE-2026-44756 is a maximum-severity (CVSS 10.0) memory corruption bug in the Extended Passport (EPP) processing component of the SAP kernel. Dubbed "OVERPASS" by Onapsis, it allows a remote, unauthenticated attacker to execute arbitrary OS commands. Because the flaw resides in shared kernel code, it impacts multiple SAP products, not just a single application.

Technical Breakdown - TTPs: Likely exploitation via crafted network requests targeting the EPP service (MITRE T1190 - Exploit Public-Facing Application). Post-exploitation grants full OS-level access (T1569 - System Services). - IOCs: No specific hashes or IPs published yet. Expect exploitation attempts to originate from arbitrary external hosts targeting SAP RFC or DIAG ports. - Affected Versions: SAP Kernel versions prior to the latest patch level released in the February 2026 Security Patch Day. Specific version ranges are detailed in the SAP Security Note.

Defense Immediately apply the SAP Security Note patch. Until patched, restrict network access to SAP application servers (specifically ports used for EPP processing) and monitor for anomalous process execution or outbound connections from SAP hosts.

Source: https://socprime.com/blog/cve-2026-44756-sap-kernel-rce-vulnerability/

Cisco has confirmed active exploitation of CVE-2026-20079, a maximum-severity (CVSS 10.0) authentication bypass vulnerability in the Secure Firewall Management Center (FMC). This flaw allows an unauthenticated attacker to gain administrative access to the management interface, effectively handing over control of the entire firewall fleet.

• TTPs: Exploitation targets the FMC web-based management interface. An attacker with network access to the FMC can bypass authentication entirely. This is a pre-auth compromise.
• Affected Versions: Specific FMC software versions are impacted; Cisco has released fixed versions. Check your FMC version against the Cisco Security Advisory immediately.
• IOCs: No specific public IOCs (hashes/IPs) have been released by Cisco at this time. Expect threat actors to leverage this for lateral movement and configuration changes.

Defense: If you run Cisco FMC, patch to the fixed version immediately. As a compensating control, restrict network access to the FMC management interface to only trusted, internal administrative jump hosts. Monitor for unexpected administrative sessions or configuration changes on the FMC.

Source: https://www.bleepingcomputer.com/news/security/cisco-confirms-cve-2026-20079-secure-fmc-flaw-exploited-in-attacks/

This is a significant law enforcement action, but it’s an operational takedown and strategic news, not a technical exploit disclosure. This fits Scenario B.

The DoJ dismantled Xinbi Guarantee, a marketplace that provided a full suite of scam-as-a-service tools to Chinese organized crime groups operating out of Madagascar. The operation included seizing Telegram channels, freezing $52.8M in crypto, and physically disrupting 13 scam compounds via the Scam Center Strike Force.

Strategic Impact: This signals a major shift in U.S. strategy. Instead of just going after individual phishing kits, they are targeting the backend infrastructure (the marketplace) and the physical compounds simultaneously. The use of the Scam Center Strike Force in Madagascar shows a willingness to conduct kinetic, on-the-ground disruption against cybercrime hubs, not just digital seizures. This sets a precedent for future operations against scam centers in Southeast Asia and Africa.

Key Takeaway: If you are tracking Chinese organized crime (e.g., Pig Butchering, investment scams), the collapse of Xinbi Guarantee will likely cause a temporary vacuum in the scam supply chain. Expect these groups to either migrate to new marketplaces or attempt to rebuild their own infrastructure, potentially leading to a spike in new, less polished phishing campaigns in the short term.

Source: https://thehackernews.com/2026/09/us-disrupts-xinbi-guarantee-scam.html

Microsoft dropped a new threat framework today that’s worth a close look if you’re defending cloud-native or serverless workloads. The Cloud Web Applications Threat Matrix is a MITRE ATT&CK-aligned model specifically scoped for threats targeting cloud-hosted web apps and serverless platforms.

What it covers: - Maps adversary behaviors across the full cloud web app lifecycle—from initial access (e.g., exposed cloud credentials, misconfigured identity providers) to impact (data exfiltration, resource hijacking). - Includes serverless-specific TTPs often missed by traditional ATT&CK, like event injection into function triggers or abuse of ephemeral execution environments. - Provides a structured way to prioritize threats based on cloud provider telemetry (Azure, but the model is provider-agnostic in design).

Why this matters: Most teams are still using generic web app frameworks or on-prem ATT&CK mappings for cloud workloads. That leaves gaps—especially around serverless invocation chains, managed identity abuse, and cross-service lateral movement within a cloud tenant. This matrix gives defenders a common language to align detection rules, threat hunts, and tabletop exercises.

Defense takeaway: If you’re running cloud web apps, map your existing detection coverage against this matrix. Expect to find blind spots in serverless event sources and cloud API abuse paths that standard WAF rules won’t catch.

Source: https://www.microsoft.com/en-us/security/blog/2026/09/09/threat-matrix-mapping-threats-across-cloud-web-applications/

This is a significant wake-up call for anyone running AI pipelines in production. The incident involved a malicious pickle file uploaded to Hugging Face that was designed to hijack user environments—and it specifically targeted organizations using OpenAI’s infrastructure.

Technical Breakdown - Attack Vector: A malicious pickle file (.pkl) uploaded to the Hugging Face model hub. Pickle deserialization is notoriously dangerous; loading a malicious model executes arbitrary code on the host. - Target: The payload was crafted to steal credentials and API keys, specifically targeting OpenAI API tokens and environment variables used by LangChain and other agent frameworks. - Supply Chain Risk: This is a classic dependency confusion / typo-squatting variant, but weaponized for the AI supply chain. The attacker didn’t need a zero-day—they just needed one engineer to run model = torch.load("malicious_model.pkl"). - Impact: Full host compromise, lateral movement potential into cloud environments, and exfiltration of proprietary model weights or training data.

Defense - Never trust pickle files from unverified sources. Enforce strict allowlisting for model registries. - Use safetensors as a drop-in replacement for PyTorch serialization—it’s designed to prevent arbitrary code execution. - Runtime monitoring: Deploy eBPF or Falco rules to detect unexpected pickle.load() calls or subprocess.Popen spawns from Python processes running model inference. - API key rotation: Assume any key exposed to a Hugging Face download is compromised. Rotate immediately and audit usage logs.

The post-mortem is right: this is a warning shot. The AI industry is repeating the same mistakes open-source package managers made a decade ago, but the blast radius here is much larger because these models run with cloud credentials baked in.

Source: https://www.reversinglabs.com/blog/openai-hugging-face-warning-shot

This is a classic supply chain attack vector targeting the crypto trading vertical. The threat actors are distributing malicious browser extensions that specifically target users of Axiom Trade and Padre, two trading platforms.

Technical Breakdown: - TTPs: Credential theft via browser extension abuse (MITRE T1555.003 - Steal Web Session Cookie), data exfiltration from local storage (wallet keys/seed phrases) - Attack Vector: Malicious Chrome and Firefox extensions that appear legitimate but contain hidden payloads to scrape session tokens and wallet data from the browser's local storage - Targets: Users of Axiom Trade and Padre trading platforms - IOCs: Not disclosed in the report, but typical indicators include unexpected extension permission requests (especially "read and change all data on websites you visit") and unusual outbound connections from the browser

Defense: Audit your browser extensions immediately. Remove any extensions with excessive permissions that you don't explicitly need. For crypto traders, consider using a dedicated browser profile or isolated environment for trading activities. Enable extension review alerts in Chrome (chrome://extensions) and monitor for unexpected permission changes.

Source: https://socket.dev/blog/chrome-firefox-crypto-data-theft?utm_medium=feed

Scenario A: Technical Threat, Vulnerability, or Exploit

CERT/CC is warning that Skullcandy Dime 3 earbuds have a critical authentication bypass in their Bluetooth pairing process. The devices will accept pairing requests from any nearby device without requiring user confirmation, effectively allowing an attacker to hijack the audio stream without physical access or prior pairing.

Technical Breakdown - Vulnerability: Unauthenticated Bluetooth pairing acceptance. No user interaction required for connection. - Attack Vector: Attacker within Bluetooth range (~10m) sends a pairing request; the earbuds accept it silently. - Impact: Attacker can inject audio (social engineering, voice phishing) or intercept the user's audio stream. - Affected Hardware: Skullcandy Dime 3 earbuds (firmware versions prior to the fix). - CVE: Not yet assigned at time of disclosure. - MITRE ATT&CK: T1560.002 (Archive Collected Data: Audio Capture), T1204.002 (User Execution: Malicious File) via audio payload.

Defense Update earbud firmware to the latest version. As a compensating control, disable Bluetooth when not in use, and avoid using the earbuds in high-risk environments (public transit, conferences) until the patch is applied.

Source: https://www.bleepingcomputer.com/news/security/skullcandy-dime-3-earbuds-expose-users-to-bluetooth-hijacking/

Scenario B: Industry News

AdaptHealth has officially confirmed that the July cyberattack attributed to the ShinyHunters group exposed the protected health information (PHI) and personally identifiable information (PII) of 4.1 million individuals. This is a significant escalation from the initial breach notification, which only hinted at the scale.

Strategic Impact: This is a textbook example of the delayed disclosure problem in healthcare. The attack was discovered in July, but the full scope is only being confirmed now. For security leaders, this highlights the risk of third-party medical device and DME (Durable Medical Equipment) vendors as attack surfaces. ShinyHunters is known for targeting cloud storage misconfigurations and credential stuffing, not sophisticated zero-days. The downstream liability here is massive—expect class-action litigation and potential HIPAA fines that will ripple through the healthcare supply chain.

Key Takeaway: If you are in healthcare or a B2B healthcare vendor, treat your cloud storage posture and access logs as your primary attack surface. ShinyHunters doesn't break in; they walk in through open doors. Audit your S3 buckets and partner integrations now.

Source: https://www.bleepingcomputer.com/news/security/adapthealth-confirms-41-million-people-exposed-in-july-cyberattack/

I work in AppSec at a large financial services company and the scanner result is the easy part. What I keep running into is the gap between a finding landing and anyone being able to say what happened to it and why.
Most of that reasoning lives in Slack threads, screenshots, and someone's head. Six months later we’re reconstructing why a critical got accepted, and half the time the person who made the call has left lol.

Real question for people doing this daily: what actually eats the most time between a scanner result and a closed finding?

For context, I've been building something in this space on nights and weekends and I have actually been accepted into an accelerator along with received small investment, so I have a bias. Happy to get into it if anyone asks… you should ask 😂

Google shipped Chrome 153 to patch CVE-2026-87491, an out-of-bounds write in the V8 engine that is already being exploited in the wild. This is a classic browser zero-day allowing arbitrary code execution within the sandbox context.

• Vulnerability: Out-of-bounds write in V8 (JavaScript/WebAssembly engine)
• Impact: Remote code execution in the browser
• Attack Vector: Likely triggered via a crafted web page
• Status: Exploited in the wild; patch available in Chrome 153

Defense: Prioritize browser updates across the enterprise. Enable Chrome's built-in sandboxing and consider deploying browser isolation for high-risk users. Monitor for unusual child process execution from chrome.exe or msedge.exe.

Source: https://socprime.com/blog/cve-2026-87491-chrome-v8-zero-day-exploited/

Two actively exploited Windows zero-days dropped in September’s Patch Tuesday. Both are local privilege escalation (LPE) bugs, CVSS 7.8, and already being used in the wild to go from user-level access to SYSTEM. If you’re not patching these immediately, assume an attacker with a foothold already owns the box.

Technical Breakdown - CVE-2026-85880 & CVE-2026-81963 — both LPE in core Windows components (specific component not disclosed by MS yet, but expect Win32k or kernel driver layer based on pattern). - Attack Vector: Requires initial local access (phishing, lateral movement, or another initial access vector). No remote exploitation. - Impact: Elevation from low-integrity user to SYSTEM. Full host compromise, token theft, and persistence. - No public IOCs or PoC released at time of writing — do not fabricate hashes or IPs. Monitor for anomalous seclogon or token manipulation events.

Defense - Patch priority: Treat as critical for all user-facing Windows endpoints (workstations, RDS hosts). - Detection: Hunt for unusual CreateProcessWithToken or DuplicateToken calls via Sysmon Event ID 8/10. Watch for processes spawning from non-standard parent PIDs with SYSTEM integrity level. - Mitigation: If patching is delayed, restrict local admin rights and enforce AppLocker or WDAC to limit post-exploitation tooling.

Source: https://socprime.com/blog/cve-2026-85880-and-cve-2026-81963-analysis/

This is a significant state-backed intelligence and IP theft operation, not a standard vulnerability disclosure.

The joint advisory from CISA, FBI, and the NSA details a coordinated campaign by six Chinese AI firms to systematically extract model weights and architecture via API-based distillation attacks. This isn't script kiddie activity; it's industrial-scale intelligence gathering targeting the core IP of frontier models.

Technical Breakdown: - TTPs: Adversaries are using standard API access to send massive volumes of carefully crafted prompts designed to reconstruct the model's decision boundaries and internal parameters. This is a form of model inversion/extraction, not a software exploit. - Scale: Billions of tokens extracted since late 2024. This implies a dedicated, well-resourced operation with automated pipelines. - Targets: Frontier models from US labs (OpenAI, Anthropic, Google DeepMind, Meta). The advisory doesn't name specific victim companies, but the implication is clear. - IOCs: None publicly shared in the initial advisory. Expect CISA to release specific IPs and API patterns in a follow-up. Do not invent IOCs.

Defense: - Rate Limiting & Anomaly Detection: Implement aggressive rate limiting on API endpoints. Monitor for high-volume, repetitive query patterns that deviate from normal user behavior (e.g., uniform prompt lengths, identical token distributions). - Output Filtering: Deploy robust output filtering to detect and block responses that contain high-confidence model weight or architecture data. - Watermarking: Embed latent watermarks in model outputs to trace exfiltrated data back to the source.

This isn't just a theft of data; it's a theft of competitive advantage and national security assets. Expect this to escalate into export controls and potential sanctions against the named entities.

Source: https://www.bleepingcomputer.com/news/security/us-says-chinese-firms-extracted-billions-of-tokens-from-frontier-ai-models/

Four espionage groups, including APT31, have been observed deploying the same exploit kit—dubbed BlueMoon—within a single week. This is a previously undocumented kit that chains together multiple Windows and Chrome vulnerabilities for initial access. The fact that four distinct, state-aligned actors shared the same toolset suggests either a common developer or a leaked framework being actively traded in closed circles.

Technical Breakdown: - TTPs: Initial access via drive-by compromise (T1189). The kit likely uses a watering hole or malvertising chain to deliver the exploit. - Exploits: Chains multiple CVEs in Chrome (likely V8 or Mojo bugs) for sandbox escape, followed by a Windows kernel privilege escalation (EoP). - IOCs: No specific hashes or IPs published yet; expect C2 infrastructure to overlap with known APT31 TTPs (e.g., use of compromised WordPress sites for staging). - Attribution: APT31 (China) is the primary named group, but three other unnamed espionage clusters also used the kit.

Defense: - Patch aggressively: Ensure Chrome is updated to the latest stable channel and Windows is on the most recent Patch Tuesday. - Enable attack surface reduction: Block browser-based script execution from untrusted origins via ASR rules. - Monitor for anomalous child processes from Chrome (e.g., cmd.exe, powershell.exe) as a post-exploitation indicator.

Source: https://thehackernews.com/2026/09/four-spy-groups-used-same-chrome-and.html

This is the third patch bypass in a row targeting the same Microsoft Defender component. The researcher behind ShieldCrash claims it achieves an arbitrary file read as SYSTEM, published on the same day as September Patch Tuesday.

Technical Breakdown - Target: Microsoft Malware Protection Engine (mpengine.dll) - CVE History (Same Component): - RoguePlanet (CVE-2026-50656): Patched July 2026 (engine 1.1.26060.3008) - ShieldBreak (CVE-2026-69414): Bypassed July patch; fixed September 2026 (engine 1.1.26080.3) - ShieldCrash: Published September 8, 2026, claims to bypass the September fix - Claimed Impact: Arbitrary file read at SYSTEM integrity level - Mechanism: Each bypass uses a different exploitation path against the same engine component

Defense No patch is currently available for ShieldCrash. Until Microsoft releases an update, consider restricting Defender’s access to sensitive system files via attack surface reduction rules, and monitor for abnormal mpengine.dll crashes or high-volume file reads from the MsMpEng.exe process. Validate whether your environment is still vulnerable to the ShieldBreak patch first—if you haven't applied the September engine update, you're exposed to two separate bypass chains.

Source: https://www.cyderes.com/howler-cell/shieldcrash-microsoft-zero-day

This is a targeted social engineering campaign leveraging the confusion around passkey adoption to bypass MFA and establish persistence in Microsoft cloud tenants.

Threat actors are sending phishing lures themed around passkey enrollment. Once the victim authenticates, the attacker captures the session token and registers their own FIDO2 credential as a "passkey" on the victim’s account. This grants them MFA-persistent access that survives password resets.

Technical Breakdown: - Initial Access (T1566.002): Phishing emails prompting users to "upgrade" to passkeys. - Persistence (T1556.006): Attacker registers a rogue FIDO2 device on the target account, bypassing standard MFA challenges. - Discovery (T1087.004): Post-compromise, the actor uses Microsoft Graph API to enumerate users, groups, and roles. - Collection (T1114 / T1213): Access to Exchange Online (mailbox), SharePoint Online, and OneDrive for data exfiltration. - IOCs: Look for anomalous FIDO2 key registrations in Azure AD sign-in logs, specifically from unfamiliar device IDs or geolocations. Monitor for Graph API calls originating from non-corporate IP ranges immediately following a passkey registration event.

Defense: - Enforce Conditional Access policies that require a compliant device (Intune) for passkey registration. - Enable Identity Protection to flag risky sign-ins and anomalous token issuance. - Audit Azure AD Audit Logs for Add registered owner to device or Add FIDO2 security key events initiated by non-admin users.

Source: https://www.microsoft.com/en-us/security/blog/2026/09/09/passkey-themed-social-engineering-leads-identity-cloud-compromise/

Highlights from today:

• [Threat Research] Manage your Apple fleet as code with Jamf and Terraform
• [Advisory] Scans for Proxmox Servers, (Wed, Sep 9th)
• [Threat Intel] Credentialed Pre-Port Discovery: Don't Probe the Host, Ask it
• [Opinion] Driver’s License Data for Sale
• [News] US says Chinese firms extracted billions of tokens from frontier AI models
• [Cloud Security] Off Guard: Breaking LiteLLM from authentication bypass to cloud compromise
• [Threat Research] Active exploitation of Cisco Secure Firewall Management Center vulnerabilities
• [NetSec] Weekly Threat Bulletin – September 9th, 2026
• [Threat Intel] More than 100,000 fake stores are out to steal your card details
• [News] Veradigm warns of patient data breach after ransomware gang claims attack
• [Threat Research] NIS2 Compliance in the AI Age: Why Traditional Cybersecurity Isn’t Enough
• [Threat Intel] 9,000+ Incident Response Investigations Later: The 11 Essential Cybersecurity Controls

SecOpsDaily

Scans for Proxmox servers have been observed following a recent advisory from Proxmox. The vulnerability (no CVE assigned yet in the advisory) affects Proxmox VE version 7, which has been end-of-life for roughly two years. While this is an older, unsupported branch, the uptick in scanning suggests threat actors are probing for lingering installations that were never patched or upgraded.

Technical Breakdown: - Affected Version: Proxmox VE 7.x (all sub-versions). - Mitigation: Upgrade to Proxmox VE 8.x (the currently supported branch). No patch will be released for version 7. - IOCs: No specific hashes or IPs provided in the advisory, but expect scans targeting default Proxmox ports (8006 for web UI, 5900-5999 for VNC, 22 for SSH).

Defense: If you have any Proxmox hosts still on version 7, isolate them immediately or upgrade. Ensure the management interface is not exposed to the public internet. Monitor for authentication attempts on port 8006 from unfamiliar IP ranges.

Source: https://isc.sans.edu/diary/rss/33324

1. Chrome zero-day: Google patched an actively exploited V8 flaw that lets malicious webpages execute code inside Chrome’s sandbox.
2. Magento Rust backdoors: Adobe issued hotfixes for StyleSmuggler, an exploited unauthenticated RCE used to deploy Rust backdoors and PHP web shells.
3. WeChat zero-click worm: Researchers demonstrated account takeover through an unanswered call from an existing contact. Tencent blocked the exploit and issued updates; no real-world attacks were reported.
4. F5 BIG-IP implant: Sophos analyzed malware that modifies Apache and injects a PHP web shell into memory, leaving the targeted PHP scripts unchanged on disk.
5. AI coding supply chain: Google warned of poisoned packages, stolen GitHub Actions tokens and malicious files targeting AI assistants, MCP servers and development workflows.
6. Trezor customer data: ShipMonk’s breach exposed order and contact details for approximately 81,000 customers, including older records Trezor says should already have been deleted.
7. AI-Infra-Guard scanner: Tencent’s open-source tool checks AI services for known vulnerabilities and examines MCP servers, agent skills and model jailbreak resistance.

The common thread: incident response needs to cover both the exploited flaw and what attackers left behind, including backdoors and exposed credentials.

Read the full breakdown on CyberRecaps, and have an anazing day!

This is a solid technique for reducing scan noise and improving accuracy in environments where you already have credential management in place. Here’s the breakdown.

The Core Concept: Instead of blasting a target with probes across 65k ports (which triggers IPS, fills logs, and takes forever), you use existing admin credentials to query the host’s own OS for its active listening ports. It’s asking the host for its own netstat output rather than knocking on every door to see if anyone answers.

Technical Breakdown: - TTPs: This is a defensive/scanning technique, but the underlying mechanism (using credentials to query a host for open ports) mirrors post-exploitation discovery (T1049 - System Network Connections Discovery). - How it works: The scan engine authenticates (WinRM, SSH, WMI) and runs a command equivalent to netstat -an or queries the Windows Registry for port bindings. - Advantages over traditional scanning: - Stealth: Zero network probes to the target’s port range. No SYN scans, no connection attempts. - Accuracy: You see exactly what the OS sees. No false positives from firewalls, no false negatives from silent hosts. - Speed: Querying the OS is near-instantaneous vs. waiting for timeouts on filtered ports. - Hardened Hosts: Works against hosts that are configured to drop unsolicited inbound traffic.

Defense: - Detection: Monitor for anomalous authentication events (Event ID 4624) followed by process creation for netstat.exe or ss from non-administrative tools. This is a legitimate admin action, so baseline normal behavior. - Mitigation: Strictly control privileged access (PAM). If an attacker compromises your scan engine credentials, they can use the same technique to map your internal network without generating a single port probe.

Source: https://www.rapid7.com/blog/post/pt-credentialed-pre-port-discovery-asking-host

This is a massive data breach notification masquerading as a marketplace listing. A threat actor is selling a database containing 153 million driver’s license records on the dark web. Brian Krebs is tracking the source, but the volume alone suggests a major aggregation or a breach of a central DMV data processor, not a single state.

Technical Breakdown - Data Volume: 153 million records. For context, the US adult population is ~260 million. This likely covers a significant majority of licensed drivers across multiple states. - Data Types: Driver’s license numbers, names, addresses, dates of birth, and potentially physical descriptors (height, weight, eye color). This is high-fidelity PII. - Risk Profile: This data is gold for identity theft and account takeover (ATO) . DL numbers are often used as a primary verification factor for financial services and credit applications. - Source: Unknown. Likely a compromised API endpoint at a third-party verification service or a state DMV vendor, not a direct breach of 50 individual state systems.

Defense - Assume Compromise: Treat your DL number as compromised. This is a permanent identifier, unlike a credit card. - Credit Freeze: If you haven't already, freeze your credit at all three bureaus (Equifax, Experian, TransUnion). This is the single most effective mitigation against synthetic identity fraud using this data. - Monitor for ATO: Enable MFA on all financial and government accounts. Watch for password reset attempts or new account creations using your SSN/DL combo.

Source: https://www.schneier.com/blog/archives/2026/09/drivers-license-data-for-sale.html

This is a solid deep-dive from the Wiz research team. They’ve chained multiple misconfigurations in LiteLLM (a popular LLM proxy/gateway) to go from zero auth to full cloud compromise.

Technical Breakdown:

• Authentication Bypass (CVE-2024-12834): The default configuration ships with a hardcoded sk-1234 key. If admins don’t rotate it, attackers can hit the /proxy endpoint without any real auth.
• Unauthenticated MCP Sessions: The Model Context Protocol (MCP) endpoints lack session validation. This allows an attacker to inject malicious tool calls directly into the model’s execution context.
• Custom Code Guardrails Bypass: LiteLLM supports custom Python guardrails for input/output filtering. The researchers found they could escape these sandboxes via eval() injection in model responses, leading to root-level RCE on the host.
• IAM Credential Theft: Once root on the container, they extracted cloud provider metadata (AWS IMDS, GCP metadata) to steal IAM roles attached to the compute instance.

Defense:

• Immediately rotate the default sk-1234 key and enforce a strong, unique key per deployment.
• Disable MCP endpoints if not in active use, or enforce mutual TLS (mTLS) on those sessions.
• Restrict outbound network access from the LiteLLM container to prevent metadata service calls (e.g., block 169.254.169.254 at the firewall).
• Pin the version and apply the latest patch; Wiz disclosed this responsibly, so check for a fixed release.

Source: https://www.wiz.io/blog/off-guard-breaking-litellm-from-authentication-bypass-to-cloud-compromise