ISR03: Insecure Configurations

How ISR03: Insecure Configurations works

Insecure configurations are hosts and services that ship or drift into a weaker state than the documented baseline. They live on domain-joined workstations, member servers, hypervisors and appliances - anywhere a build was cloned once and never reconciled since.

The state survives because it is invisible to a patch scanner: every package is current, yet the service ACL is world-writable, the name-resolution stack still broadcasts, and no golden image or drift detector exists to notice. After initial access it turns one foothold into many - a local privilege escalation, a captured credential, a service takeover - without a single exploit. The three chapters below take one surface each: Unhardened System Baselines covers absent or drifted CIS/STIG state across a fleet, LLMNR And NBT-NS Name Poisoning covers the broadcast resolution fallback that hands out NetNTLM material, and Insecure Service Permissions And Unquoted Paths covers escalation from weak ACLs and writable paths alone.

Keywords: cis benchmark, stig, configuration drift, llmnr, unquoted service path, service acl

Examples/Proof

• Baseline variance sample
  • Pull one registry or sysctl key that the baseline pins across ten hosts that should be identical. Any spread of values means no configuration management is enforcing the build.
• Broadcast resolution listen
  • Passively watch UDP 5355 and 137 on a segment. LLMNR or NBT-NS query traffic proves the fallback is enabled and answerable by any host.
• Writable service binary
  • Enumerate service image paths and test the target directory for write access as a standard user. A writable path under an auto-start service is a confirmed escalation route.
• Unquoted path with a gap
  • List services whose ImagePath contains a space and is not quoted. A writable directory earlier in the path than the real binary is exploitable at next service start.

Detection and Monitoring

• Benchmark scan delta
  • Compare a scheduled CIS/STIG scan against the last run. New failing controls on a host that did not change ownership indicate silent drift.
• Name-resolution counters
  • Alert on LLMNR (UDP 5355) and NBT-NS (UDP 137) query volume from clients where DNS should be authoritative; sustained traffic means the fallback was never disabled.
• Service configuration change events
  • Watch Windows Event ID 7040 (service start-type change) and 4697 (service install) on servers; an unexpected change outside a maintenance window is suspect.

How to fix and prevent ISR03: Insecure Configurations

1. Define one golden image per role and version it
   • Build workstations and each server role from a single hardened image mapped to a named CIS or STIG level.
2. Enforce the baseline with configuration management
   • Push state through GPO, Ansible, DSC or Intune so a host that drifts is corrected on the next cycle, not at the next audit.
3. Scan for drift on a schedule, not on demand
   • Run a benchmark scanner fleet-wide and diff results between runs. Partial control: a scanner only flags what its policy covers, so keep the policy current.
4. Disable the broadcast resolution fallback estate-wide
   • Turn off LLMNR, NBT-NS and mDNS by policy so a mistyped name fails closed instead of being answered by an attacker.
5. Lock service and path permissions in the image
   • Quote every service path, remove SERVICE_CHANGE_CONFIG from non-admins, and keep %PATH% and service directories off any standard-user-writable location.

Prevention Checklist

• Every host role builds from a single versioned hardened image mapped to a named benchmark level
• A configuration-management system reconciles baseline state on a fixed cycle
• A benchmark scanner runs fleet-wide on a schedule and its output is diffed between runs
• LLMNR, NBT-NS and mDNS are disabled by policy across the estate

Last updated 2026-08-24