April 2026 Patch Tuesday: Focus on Defender 'BlueHammer' & Chrome 0-Day #4
Hey team, just digging through the April dump. While the count of 167 CVEs is staggering, I'm particularly concerned about the publicly disclosed weakness in Windows Defender dubbed 'BlueHammer'. Since it's publicly disclosed and tied to Defender, I'm expecting exploit samples to drop soon.
Microsoft also addressed that SharePoint zero-day (CVE-2026-30123), but if you are cloud-hosted, Microsoft likely handled the backend patching already. However, the on-prem folks need to move fast.
Also, don't overlook the Google Chrome update—it's their fourth zero-day of the year. And on the Adobe side, that emergency update for CVE-2026-34621 (RCE) is critical given the active exploitation reports.
I'm checking the status of our Defender engines across the fleet to ensure we aren't vulnerable to the BlueHammer bypass until the definition updates fully propagate. Here is a quick PowerShell snippet to verify your Tamper Protection and Real-time protection status:
Get-MpComputerStatus | Select-Object IoavProtectionEnabled, RealTimeProtectionEnabled, TamperProtectionEnabled, AntivirusSignatureVersion
For those hunting for the Adobe exploitation, we are using the following KQL query to spot suspicious child processes spawned by Acrobat:
DeviceProcessEvents
| where InitiatingProcessFileName =~ "AcroRd32.exe"
| where FileName in~ ("cmd.exe", "powershell.exe", "wscript.exe", "mshta.exe")
| project Timestamp, DeviceName, InitiatingProcessCommandLine, FileName, ProcessCommandLine
Is anyone else seeing issues with the Defender definition updates rolling out slowly, or is it just my WSUS server being laggy today?
Thanks for the KQL query. We actually caught a staging attempt of the Adobe exploit (CVE-2026-34621) late last night. The payload was attempting to drop a DLL into C:\ProgramData\. The query you shared actually flags it perfectly because it spawns powershell.exe with an encoded command. Definitely patch Adobe Reader before you grab your morning coffee.
The BlueHammer flaw is interesting because it doesn't disable Defender but bypasses specific heuristics. I'm seeing reports that it relies on a specific file renaming convention to evade AMSI scanning. We've added a block rule for the specific hash family associated with the Proof-of-Concept, but I agree, definition propagation is the weak link right now.
Regarding the SharePoint zero-day: If you haven't applied the patch yet, restrict access to the _layouts/15 or _vti_bin directories on your external-facing servers immediately. We are seeing heavy scanning attempts for CVE-2026-30123 originating from a few specific ASN ranges in Eastern Europe. Better safe than sorry with RCEs.
That's a critical mitigation for SharePoint, Eve. For the BlueHammer issue in Defender, verifying AMSI integrity via PowerShell is a solid step. Run this command on suspect workstations to check for recent attempts to load untrusted assemblies:
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Windows Defender/Operational'; ID=1116} | Select-Object TimeCreated, Message | Format-List
Has anyone observed if specific versions of PowerShell (5.1 vs 7) are more susceptible to the bypass heuristics Chris mentioned?
Good catch on the renaming technique, Chris. To complement the AMSI checks, we can hunt for the filesystem artifacts of that behavior. Since BlueHammer relies on specific renaming, looking for executables created in user directories that were renamed shortly after creation is a strong indicator. Here is a KQL query to hunt for those rapid file renames:
DeviceFileEvents
| where Timestamp > ago(24h)
| where ActionType == "FileRenamed"
| where FolderPath contains @"Users" and FileName endswith ".exe"
| project DeviceName, FileName, PreviousFileName, InitiatingProcessAccountName
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access