A municipal elevated application loads DLLs from a path writable by a standard user. What privilege-escalation class should the tester investigate carefully?
Select an answer to reveal the explanation.
Short Explanation
If a privileged app looks for a DLL in a folder you can write, you may get to plant the library it trusts. That DLL hijack class needs careful validation—false paths happen. It is about load order and ACLs, not Secure Boot or zone transfers.
Full Explanation
A municipal elevated application that loads DLLs from a path writable by a standard user invites DLL search-order or hijack themes: the elevated process may load an attacker-controlled library from the writable location. Investigate carefully within RoE and avoid unnecessary instability on production civic apps.
Writable DLL paths are not exclusive proof that UEFI Secure Boot is disabled fleet-wide. They are not DNS zone-transfer failures. They do not confirm PowerShell Constrained Language Mode is fully enforcing.
Exam caveat: distinguish true hijackable search order from merely interesting writable folders adjacent to apps.
Operational check: identify elevated processes and their DLL search/load paths, test writability of candidate directories safely, and recommend safe library directories with tight ACLs for city applications. In municipal operations, record the rationale in the engagement notes so future assessors know which control was chosen and which failure modes the rejected options would create for city services. Re-validate after the next maintenance window that the same finding class still applies under the estate's current patch and configuration baseline. In municipal operations, record the rationale in the engagement notes so future assessors know which control was chosen and which failure modes the rejected options would create for city services.