Weekend Roundup: Fiber Taps, Rootkits, and that Acrobat Zero-Day

We're seeing indicators of this in our SIEM already. The exploit chain seems to drop a shell that attempts to bypass UAC immediately. We deployed a quick Sigma rule to catch Acrobat spawning child processes it shouldn't:

detection:
  selection:
    ParentImage|endswith: '\AcroRd32.exe'
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
  condition: selection

Blocking at the mail gateway isn't an option for us due to business requirements, so we're relying heavily on EDR detection rules for now.

The fiber optic aspect is what terrifies me. You can patch a server, but you can't patch a physical splice in a data center conduit. It highlights the massive blind spot we have regarding hardware supply chain integrity. On the Acrobat front, we are forcing the Chrome PDF viewer as the default handler via GPO until our patch cycle completes on Friday. It's a clumsy fix, but it reduces the attack surface significantly while we wait.

The Acrobat zero-day is definitely the priority right now. While you wait for the patch to propagate, consider enabling Microsoft Defender's Exploit Protection for Acrobat Reader to mitigate RCE attempts. You can audit the current configuration with this PowerShell command:

Get-ProcessMitigation -Name AcroRd32.exe | Select-Object Name, @{N='ASLR';E={$_.ASLR}}, @{N='DEP';E={$_.DEP}}

This helps verify if randomization and DEP are actually active on your endpoints.

That Acrobat zero-day is nasty, especially with the active exploitation. In addition to Defender Exploit Protection, you can mitigate the impact by enforcing Protected View in the registry for files from the Internet. It forces a sandboxed environment before the document opens. Here's a quick PowerShell snippet to check if it's enabled:

Get-ItemProperty -Path 'HKCU:\Software\Adobe\Acrobat Reader\DC\AVGeneral\cSecureOpen' -Name 'iProtectedView'

Since we're talking about defense-in-depth, if you can't patch instantly, consider disabling JavaScript in Acrobat Reader entirely. It breaks a lot of exploit chains. Here’s a registry tweak to enforce it:

$regPath = "HKCU:\Software\Adobe\Acrobat Reader\DC\JSPrefs"
if (!(Test-Path $regPath)) { New-Item -Path $regPath -Force }
Set-ItemProperty -Path $regPath -Name "bEnableJS" -Value 0

Combine this with Dana's Protected View suggestion, and you significantly reduce the attack surface while waiting for the deployment queues to clear.

Solid advice on mitigation layers. To add to CryptoKatie's point about Acrobat spawning shells, you should enforce the specific Attack Surface Reduction (ASR) rule: 'Block Adobe Reader from creating child processes'. This effectively stops the post-exploitation payload from executing.

To verify your current ASR configuration:

Get-MpPreference | Select-Object AttackSurfaceReductionRules_Ids, AttackSurfaceReductionRules_Actions

Look for GUID BE9BA2D9-53EA-4CDC-84E5-9B1EEEE46550 set to audit (2) or block (1).

To build on CryptoKatie's point about the SIEM indicators, if you need to hunt for active infections on specific endpoints where EDR might be blind, you can use PowerShell to check for Acrobat spawning suspicious child processes. This query checks the Security event log for Acrobat spawning shells or PowerShell in the last 24 hours:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688; StartTime=(Get-Date).AddHours(-24)} | Where-Object {$_.Message -match 'AcroRd32.exe' -and $_.Message -match '(powershell.exe|cmd.exe)'} | Select-Object TimeCreated, Message


It’s a quick way to triage a compromised machine without waiting for log aggregation.