August 10 – August 17, 2026

Act by

• 25 Aug 2026 — CISA added CVE-2026-68820, the actively exploited Windows WinSock driver elevation of privilege fixed on 11 August, to the Known Exploited Vulnerabilities catalogue on 11 August with a remediation due date of 25 August under BOD 26-04. Federal agencies are bound by that date; for everyone else it is a reasonable ceiling on how long an exploited local SYSTEM escalation should sit unpatched. (CISA Known Exploited Vulnerabilities catalog)
• 14 Sep 2026 — the containerized data connector agent for the Microsoft Sentinel solution for SAP applications is permanently disabled and stops sending SAP logs to Sentinel. Migrate to the SAP agentless data connector before then; the migration runs side by side with no coverage gap, and existing analytics rules, workbooks, hunting queries and playbooks keep working. If you miss the date, everything built on that SAP data silently stops returning results. (Azure updates)

What changed

August Patch Tuesday landed on 11 August with one vulnerability Microsoft flags as exploited in the wild: CVE-2026-68820, a use-after-free in afd.sys, the Ancillary Function Driver for WinSock and a kernel-side component of Windows networking. A locally authenticated attacker runs a crafted application to win a race condition and gains SYSTEM, with no user interaction required. Microsoft rates it Important at CVSS 7.0, held down by the high attack complexity the race condition implies, and credits the finding to Check Point — but exploitation status, not base score, is what should drive your patch ring here, and this is the classic post-phish escalation primitive. CISA added it to the KEV catalogue the same day. The wider release is large: the Security Update Guide carries 798 CVE entries for August, though the bulk of those are Azure Linux package updates and 45 are Edge and Chromium, leaving roughly 420 across Windows, Office, SharePoint Server, Exchange and the developer tools. (MSRC Security Update Guide)

The more awkward entry in the same release is CVE-2026-69414, an elevation of privilege in the Microsoft Malware Protection Engine in Microsoft Defender that Microsoft acknowledges is publicly referred to as ShieldBreak. Microsoft says it is aware of the issue and working on a security update, and will populate the CVE when one is available — so as of the August release this is a publicly disclosed, CVSS 7.8 local privilege escalation in the antimalware engine itself, with no patch listed and customer action marked as required. The exploit-maturity metric is set to proof-of-concept, meaning working code is understood to exist. Practically, there is nothing to deploy yet; what you can do is make sure Defender platform and engine updates are actually flowing rather than pinned or blocked, keep tamper protection on so the engine cannot be interfered with from the same local foothold, and watch for the CVE to be updated. An escalation path that runs through the security agent is worth a named tracking item rather than a line in the monthly patch report. (MSRC Security Update Guide)

Microsoft Sentinel published a full hands-on lab for the connector builder agent, the VS Code based public preview that generates Codeless Connector Framework pull connectors from a natural-language prompt. The walkthrough runs against a mock network log API deployed as an Azure Function App and shows the agent working through a seven-step sequence — preparation, polling config, table schema, DCR, connector definition, package validation, summary — and emitting four JSON artifacts. It picks the endpoint, the API key auth header, NextPageUrl pagination with a stop condition, the incremental delta parameter, the custom table schema with timestamp promoted to TimeGenerated, and the KQL transform mapping snake_case API fields to PascalCase columns, pausing for human input only to confirm the connector description. The genuinely useful part for anyone onboarding a source is Test Connector, also in preview: right-click the connector folder in VS Code, supply the base URL and key, and watch a live polling session with Headers, Payload, Response and Events tabs before anything is deployed to a workspace. Prerequisites are worth checking before you plan work around it — Contributor on a resource group, Sentinel Contributor on the workspace, and GitHub Copilot with premium model credits, since the agent requires Claude Sonnet 4.5 or 4.6. (Microsoft Sentinel Blog)

Sentinel's containerized SAP data connector agent now has a hard retirement date of 14 September 2026, published as a formal retirement notice on 12 August. After that date the agent is permanently disabled and stops shipping SAP logs. The agentless data connector is generally available and is the replacement; creation of new containerized agents is already disabled, so this only affects estates still running the old container. Two details matter for planning beyond the migration itself: the agentless connector requires fewer but different authorizations on the SAP side, so the Sentinel SAP role needs reviewing rather than copying, and billing exclusions for specific SAP SIDs need revisiting because the agentless connector identifies systems differently. There is no change to pricing or billing meters. (Azure updates)

Azure Firewall Premium took a substantial IDPS throughput increase to general availability on 11 August. Combined TLS inspection and IDPS in Deny mode now sustains up to 22 Gbps, up from 10 Gbps, a 120 percent increase, and per-TCP-connection throughput with IDPS enabled in either Alert or Deny mode doubles from 300 Mbps to 600 Mbps. This is the kind of change that removes an argument rather than adds a feature: capacity headroom has been the standing reason teams leave IDPS in Alert mode or scope TLS inspection narrowly, and a doubling of per-connection throughput makes Deny mode viable on links where it previously throttled large transfers. Worth re-testing before you assume your existing sizing still constrains you. (Azure updates)

Azure Front Door gained mutual TLS in public preview on 12 August, letting the edge authenticate clients with X.509 certificates before a request ever reaches the application. There are four validation modes, and the distinction between them is where the security decision actually lives: require and validate makes a client certificate mandatory and validates it at the edge before forwarding it to the origin in the X-Azure-ClientCertificate header; require without validation makes it mandatory but leaves validation to the origin; validate when presented treats it as optional but validates any certificate that appears; and pass through to the origin forwards without validating. Only the first mode gives you edge enforcement — the other three are transport plumbing that still requires origin-side logic, which is a distinction worth pinning down when reviewing an app team's design. Front Door accepts certificates from public and private CAs, with the trusted CA chain uploaded to Azure Key Vault and associated with a custom domain. Named target scenarios are business-to-business APIs, IoT, financial services, VPN and enterprise network access. (Azure updates)

Also on Front Door, batch rule updates went generally available on 12 August for the Standard and Premium tiers. Adding, updating, deleting or reordering multiple rules in a rule set now happens as one coordinated operation that either applies in full or not at all. The failure mode this closes is worth naming because it has security consequences: individually applied rule changes can leave partial rule states or rule-order conflicts, and rule order is exactly what determines whether a blocking rule sits ahead of a permissive one. Teams driving Front Door from Terraform or other infrastructure-as-code workflows have been living with that risk plus the retry and rollback complexity around it. Batch mode is opt-in when creating a new rule set; existing rule sets keep classic rule management by default. (Azure updates)

Microsoft Entra Tenant Governance reached general availability, having been previewed back in April. It targets the estates that have accumulated dozens or hundreds of tenants — primary, production, test, demo and the shadow tenants nobody claims — with four capabilities: Related Tenants to discover and map tenant relationships, Governance Relationships for least-privileged cross-tenant delegated administration, Tenant Configuration Management to set baselines and detect configuration drift across Defender, Entra, Exchange, Intune, Purview and Teams, and Secure Tenant Creation to control who can stand up a tenant and automatically bring new ones under governance. The unmanaged legacy tenant is a real SOC problem rather than an administrative annoyance: it holds identities that still federate, it is outside your monitoring baseline, and it is nobody's on-call responsibility. Licensing is worth checking before scoping a rollout — governing tenants need a Tenant Governance license, ID Governance, Entra Suite or Microsoft E7 raise the monitoring limits, and multi-tenant agent management requires Agent 365 licences in the governed tenants. (Microsoft Entra Blog)

The Entra monthly roundup for August collects a set of identity changes with audit and lifecycle relevance. Reaching general availability: an admin-controlled registry setting that automatically accepts single sign-on permission prompts on managed Windows 11 24H2 and 25H2 devices, shipping in the July 2026 security update as KB5101650; Exchange Online managed attribute writeback to Active Directory, which moves the source of authority for a directory-synchronized mailbox's Exchange attributes to Exchange Online and syncs changes back on-premises through Cloud Sync; and four Lifecycle Workflows additions worth knowing about on shift — a what-if mode that simulates which users fall in an execution scope before you run anything, the ability to cancel queued or in-progress runs to contain a misconfigured automation, a User Attribute Updates task supporting up to ten attribute changes per task, and expanded dynamic attributes in custom email notifications. New in public preview: synchronizing on-premises Active Directory devices through Cloud Sync, closing a parity gap that previously forced Entra Connect Sync or AD FS for Hybrid Join across connected and disconnected forests; Lifecycle Workflows that automatically detect and clean up sponsorless guest accounts, which is the stale over-permissioned external user problem addressed as automation rather than a quarterly review; and automatic backup and restore of managed Group Policy Objects in Entra Domain Services. Note that the cancel-run capability does not reverse completed tasks — it only stops what has not yet processed. (Microsoft Entra Blog)

Microsoft Threat Intelligence published a teardown of DeadLock, a financially motivated ransomware family first observed in July 2025 and now deployed by multiple groups including affiliates of the Lynx and INC ecosystems. The encryptor is Rust-based and pairs Curve25519 with XChaCha20, generating an ephemeral key per file, wrapping keys with NaCl crypto_box, and varying how much of each file it encrypts from 10 to 100 percent by size, with resource-aware throttling so the host stays responsive during encryption. The pre-encryption behaviour is what your detections should be catching: geofencing that skips former Soviet and CIS-linked systems, UAC bypass via batch script elevation, termination of more than fifty security processes and services, event log clearing through three complementary methods, and emptying the recycle bin to remove a recovery path. The distinguishing feature is the extortion infrastructure — a self-contained HTML application that resolves proxy URLs and hosts leak posts through Polygon smart contracts, runs victim negotiation over the Session network's onion-routed encrypted messaging, and serves stolen files from Wasabi S3 with browser-based access. That combination is markedly more resistant to takedown and domain seizure than conventional Tor leak sites, so plan on the leak threat being credible for longer. Detection coverage exists as the Ransom:Win32/DeadLock.* signature family plus behavioural alerts for ransomware activity and backup deletion, and Microsoft's guidance is the usual configuration set that this family specifically defeats when absent: cloud-delivered protection, EDR in block mode, tamper protection, Controlled Folder Access with strict policies, the ransomware attack surface reduction rules, and automatic attack disruption in Defender XDR. (Microsoft Security Blog)

KQL to try

Correlates non-compliant or health-flagged Intune devices with LDAP reconnaissance from the same host, pairing device posture with directory enumeration. (Suspicious LDAP Reconnaissance from Non-Compliant Devices — Benjamin Zulliger)

let Lookback		= 1d;
let BinSize		= 15m;
let RiskyDevices = materialize(
	IntuneDeviceComplianceOrg
	| where TimeGenerated > ago(7d)
	| summarize arg_max(TimeGenerated, DeviceHealthThreatLevel, ComplianceState) by DeviceName
	| where DeviceHealthThreatLevel in~ ("Low", "Medium", "High")
		or ComplianceState =~ "Noncompliant"
	| extend DeviceKey = tolower(tostring(split(DeviceName, ".")[0]))
	| distinct DeviceKey, DeviceHealthThreatLevel, ComplianceState
);
// Attributes split by signal strength instead of a flat has_any
let RxHigh	= @"ms-mcs-admpwd|mslaps-(encrypted)?password|ntsecuritydescriptor|msds-allowedtodelegateto|msds-keycredentiallink|sidhistory|unixuserpassword";
let RxMed	= @"serviceprincipalname|admincount|msds-managedpassword|gplink|scriptpath";
let RxLow	= @"useraccountcontrol|memberof|member|primarygroupid|grouptype";
// LDAP matching rules and bitmask filters, almost exclusively seen from offensive tooling
let RxTool	= @"1\.2\.840\.113556\.1\.4\.1941|1\.2\.840\.113556\.1\.4\.803:=(4194304|524288|16777216|8192)";
IdentityQueryEvents
| where TimeGenerated > ago(Lookback)
| where ActionType == "LDAP query"
| where isnotempty(Query) and isnotempty(DeviceName)
| where AccountName !endswith "$"				// Computer accounts need their own baseline
| extend DeviceKey = tolower(tostring(split(DeviceName, ".")[0]))
| lookup kind=inner RiskyDevices on DeviceKey
| extend q = tolower(Query)
| extend
	ToolHit	= extract(RxTool, 0, q),
	Score	= iff(q matches regex RxHigh, 5, 0)
		+ iff(q matches regex RxMed,  2, 0)
		+ iff(q matches regex RxLow,  1, 0)
		+ iff(q matches regex RxTool, 5, 0)
		+ iff(q contains "objectcategory=person" and q contains "(&", 1, 0)
| where Score > 0
| summarize
	Events		= count(),
	DistinctQueries	= dcount(Query),
	Targets		= dcount(QueryTarget),
	MaxScore	= max(Score),
	TotalScore	= sum(Score),
	ToolIndicators	= make_set_if(ToolHit, isnotempty(ToolHit), 10),
	SampleQueries	= make_set(substring(Query, 0, 200), 8),
	IPs		= make_set(IPAddress, 5),
	TargetDCs	= make_set(DestinationDeviceName, 5),
	FirstSeen	= min(TimeGenerated),
	LastSeen	= max(TimeGenerated)
	by bin(TimeGenerated, BinSize), DeviceKey, AccountUpn, AccountDisplayName, DeviceHealthThreatLevel, ComplianceState
// Two separate triggers: single high confidence hit OR bulk enumeration
| where MaxScore >= 5 or (TotalScore >= 15 and DistinctQueries >= 20)
| extend Verdict = case(
	array_length(ToolIndicators) > 0,	"High: LDAP matching rule or bitmask filter, typical for offensive tooling",
	MaxScore >= 5,				        "High: access to highly sensitive AD attributes (LAPS/ACL/delegation)",
	DistinctQueries >= 50,			    "Medium: broad AD enumeration in a short time window",
						                "Low: elevated LDAP activity, review context")
| order by MaxScore desc, DistinctQueries desc

Worth knowing

The Entra team ran a pair of strategy posts this week rather than shipping features, and the implementation one has some reusable detail. The Zero Trust rollout guidance recommends a specific sequence for extending Conditional Access and Global Secure Access across AI apps, on-premises apps, SaaS and internet destinations: inventory the access surface first to find where policy coverage is inconsistent, keep user risk and sign-in risk in separate policies rather than combining them, start every new policy in report-only mode, exclude break-glass accounts from broad policies, and confirm the licensing prerequisite before designing around a control. The companion post argues the case for reducing Active Directory dependency and lists four priority areas — modernizing authentication toward phishing-resistant methods, moving access decisions to Conditional Access rather than network location, expanding governance to cover external and AI-related identities, and identifying the workloads still pinned to AD. Neither changes anything you operate, but the report-only and separate-risk-policy points are the two that most often get skipped in a hurry. (Microsoft Entra Blog)