Patterns from this week's pentests

Our offensive team runs weekly external, internal, and assumed-breach engagements against production estates. The most valuable artifact isn't the individual report — it's the shape of findings across a week's engagements. The same failure modes recur across different customers, stacks, and industries. Below are the four patterns that dominated our queue from 2026-08-10 to 2026-08-16: the CVEs and misconfigurations that anchored them, and what defenders should do.

Pattern 1: Reporting and BI surfaces still ship with legacy RCE primitives

Three engagements this week gained initial foothold through an internet-adjacent reporting or business-intelligence appliance. Two exploited CVE-2020-0618 against SQL Server Reporting Services (SSRS) instances patched at the OS level but running a pre-February-2020 ReportingServicesService.exe binary. The third was a Cyberoam WebAdmin exposed to a partner network, still vulnerable to CVE-2020-29574 — an unauthenticated SQL injection that yields root-equivalent execution.

The common thread is not novelty — these bugs are years old. The assets are forgotten: devolved to a business owner, excluded from EDR coverage, and absent from the CMDB the vulnerability scanner reads. Operators don't need a zero-day; they need nmap, a Metasploit module, and patience.

A minimal Sigma-style detection rule for the SSRS variant:

title: SSRS Deserialization Child Process
logsource:
  product: windows
  category: process_creation
detection:
  parent:
    ParentImage|endswith: '\ReportingServicesService.exe'
  suspicious_child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\rundll32.exe'
      - '\certutil.exe'
  condition: parent and suspicious_child
level: high

Without a rule like this, you won't see CVE-2020-0618 land. The fix: inventory every reporting service, verify the service binary build number — not just the Windows patch level — and apply the same EDR policy as the rest of your Windows fleet.

Pattern 2: Identity-adjacent appliances trust their subnet too much

Two internal engagements reached Domain Admin without exploiting a single memory-corruption bug. Both exploited the same architectural weakness: an identity-adjacent appliance — a firewall, VPN concentrator, or NAC broker — trusted LDAP responses from anywhere on the management VLAN. This is the class captured by CVE-2019-5591 in FortiOS: the default configuration accepts an impersonated LDAP server on the same subnet and surrenders cleartext bind credentials for the service account.

The pattern is within reach of a Tier-2 operator. Once on the management segment — usually via a jump host with weak segmentation — the operator ARP-poisons the appliance's route to the real DC, stands up a rogue LDAP listener with Responder or a small Python service, and waits for the appliance to authenticate. The service account is almost always over-privileged: the vendor setup guide asked for Domain Admins "for testing," and nobody rolled it back.

Two mitigations matter:

  1. Pin every appliance's LDAP client to a specific DC and require LDAPS with certificate validation. If the appliance can't do this, treat it as end-of-life for identity integration.
  2. Give appliances low-privilege service accounts with Read-only scoped delegation, and monitor for unusual LDAP binds from appliance source IPs.

Pattern 3: Post-exploit privilege escalation is still overwhelmingly a patching problem

Once operators land on a workstation or server, the LPE stage is depressingly cheap. This week's assumed-breach engagements produced privilege escalation via:

None are novel; all were patched upstream months to years ago. Linux server and appliance patch cadence lags Windows workstations by 6–18 months in most estates we assess; appliance-form-factor Linux — NAS, hypervisors, virtual appliances — lags by another year on top of that.

A minimum viable check for the PwnKit class:

# Confirm pkexec is either patched or stripped of setuid
for host in $(cat linux_hosts.txt); do
  ssh "$host" '
    v=$(pkexec --version | awk "{print \$3}")
    m=$(stat -c "%a" "$(command -v pkexec)")
    printf "%s pkexec=%s mode=%s\n" "$(hostname)" "$v" "$m"
  '
done

Any host reporting pkexec older than 0.120 with mode 4755 is exploitable today, no exceptions.

Pattern 4: Blast radius is a segmentation problem, not a credential problem

The most common finding this week was not a CVE — it was that any foothold made lateral movement to crown-jewel systems trivially easy. Flat management VLANs, ANY/ANY firewall rules between "prod" and "corp," domain-joined jump boxes with outbound internet, and shared local-admin passwords across server tiers all made repeat appearances.

The patch-and-detect pipeline is necessary but not sufficient. Assume an operator will eventually land somewhere. The question is how many hops separate that landing zone from systems whose compromise triggers regulatory notification. Our median this week was 2.3 hops. Targets that should require 6+ hops — payment processing, identity stores, backup infrastructure — were reachable in 3.

Segmentation is unglamorous. It is also the single control that most consistently converts a "critical" finding into a "high-with-limited-impact" one.

What to take back to Monday

The engagements change every week. The patterns barely move. Test yourself as an operator would, at an operator's cadence, and let evidence — not vendor claims — drive the remediation queue.

Verifiable security.