What Attackers Actually Need Administrator Rights For-and What Least Privilege Cannot Solve

Part 2 of 3 in ARCON’s Endpoint Privilege series. A practical architecture guide for security architects and endpoint engineering teams.

Key takeaways

• Removing standing local administrator rights does not stop every endpoint attack. It removes the attacker’s direct path to high-impact operations such as creating system services, loading drivers, accessing protected processes and tampering with security controls.
• Standard-user execution and administrator-level execution are not the same problem. An attacker may still run PowerShell, native utilities or malicious code as a standard user, but cannot automatically perform every privileged action.
• A LOLBAS entry marked “Privileges required: User” means that the technique can begin from a non-elevated process. It does not necessarily mean that a genuine standard account can create an administrator token.
• Windows UAC, macOS Transparency, Consent and Control, and Linux sudo, setuid, capabilities and polkit are different privilege systems. A cross-platform EPM programme must govern each one according to its native security model.
• EPM must be paired with patching, application and library control, vulnerable-driver protection, file permissions and EDR. Least privilege is a control layer, not a complete endpoint-security stack.
• Before removing administrator rights, collect real elevation data, classify legitimate use cases and test rules against a representative business cycle.

Start with the outcome, not the slogan

“Administrator rights are dangerous” is correct, but it is not specific enough to guide an endpoint architecture.
The more useful question is:

Which attacker objectives become materially easier when the compromised user already holds administrative authority?

Removing standing administrator rights does not make the endpoint invulnerable. It changes the attacker’s starting position.

Instead of immediately inheriting authority to alter protected system resources, the attacker must find another route: steal privileged credentials, exploit a local vulnerability, abuse a misconfiguration, manipulate an approved elevation rule or persuade a user or support operator to approve elevation.

That additional step matters. It creates opportunities to prevent the action, restrict its scope, require stronger identity assurance and generate evidence for investigation.

The privileged outcomes least privilege is designed to constrain

Several common adversary objectives depend on elevated operating-system authority.

MITRE states that Windows services may be created with administrator privileges and subsequently executed under SYSTEM. Its current mappings also recommend restricting user privileges so that only authorised administrators can interact with service configurations.

MITRE’s mappings for Access Token Manipulation similarly state that an adversary generally needs administrator-level access to make full use of several token-manipulation methods. The listed mitigations include Privileged Account Management and User Account Management.

The correct security claim is therefore not:

“Removing administrator rights eliminates privilege escalation.”

It is:

Removing standing administrator rights eliminates the direct use of administrator authority and forces the adversary to obtain, bypass or request elevation before performing privileged operations.

That is a narrower claim, but it is also more technically defensible.

The important distinction: user-level execution is not administrator-level execution

A standard user can still perform many actions that matter to an attacker.

Depending on endpoint configuration and application permissions, a compromised standard account may be able to:

• execute binaries and scripts.
• use PowerShell or another command interpreter.
• access files available to the compromised user.
• steal browser data or application tokens available in that user context.
• communicate with external infrastructure.
• modify user-writable registry keys and directories.
• establish user-level persistence; and
• use legitimate operating-system utilities.

Removing administrator rights does not make these capabilities disappear.

What it does is prevent the attacker from automatically converting ordinary user execution into unrestricted system administration.

That difference is especially important when discussing UAC bypasses and living-off-the-land binaries.

What “Privileges required: User” means in LOLBAS

The LOLBAS project documents legitimate Windows utilities that can be abused for execution, download, persistence, credential access, application-control bypass and other purposes.

For example, LOLBAS documents techniques involving ComputerDefaults.exe, Eventvwr.exe and odbcad32.exe that begin with a user-context process. Individual entries may therefore show “Privileges required: User.”

However, that field must be interpreted carefully.

Microsoft documents two different Windows sign-in models:

• A member of the local Administrators group receives a filtered standard-user token and a full administrator token.
• A genuine standard user does not possess that full administrator token and must provide valid administrator credentials when an administrative task is requested.

In other words, many classic UAC bypasses suppress or avoid the consent prompt for a user who already has an administrator token available. They do not magically create administrator authority for a true standard account that has no such token.

MITRE reflects this distinction directly. Its mitigation for T1548.002, Bypass User Account Control, includes:

Remove users from the local administrator group on systems.

MITRE also recommends maintaining UAC at its highest practical enforcement level and keeping Windows updated to reduce known bypass opportunities.

This changes the conclusion materially.

Removing local administrator membership does not stop living-off-the-land execution. But it can break a large class of UAC bypass paths that depend on the compromised user already possessing a full administrator token.

The resulting architecture principle is:

Use EPM to remove standing administrator authority, and use application, script and behaviour controls to govern what still runs at user level.

Privilege control and execution control solve different problems

Endpoint security programmes often treat least privilege and application control as substitutes. They are not.

Privilege control answers:

• Who may elevate?
• What may be elevated?
• Under which identity and device conditions?
• For how long?
• With whose approval?
• What happens to child processes?
• Is the elevated action automatically revoked and recorded?

Execution control answers:

• Which binaries, scripts and libraries may run?
• From which locations?
• Under which publisher, certificate, hash or version?
• Which command-line arguments are permitted?
• Can a process load an untrusted library?
• Can code execute from a user-writable location?

MITRE maps Privileged Account Management to techniques such as UAC bypass, token manipulation and certain process-injection scenarios. For T1685, Disable or Modify Tools separately lists controls including execution prevention, restricted file and directory permissions, restricted registry permissions, secure configuration and account management.

The architecture lesson is straightforward:

EPM determines when elevated authority is available. Application and library controls determine which code can use the endpoint, whether elevated or not.

Deploying one without the other leaves a predictable control gap.

Windows, macOS and Linux do not have the same privilege model

A cross-platform EPM programme cannot simply reproduce a Windows local-administrator policy on every operating system.

Windows: groups, split tokens, UAC and process elevation

On Windows, the main control points include:

• membership of local administrative groups.
• filtered and full access tokens.
• UAC policy.
• service and driver permissions.
• privileged user rights.
• executable and script elevation.
• child-process inheritance; and
• file, directory and registry permissions.

One subtle but important engineering concern is child-process handling.

Microsoft’s current Intune EPM documentation allows administrators to require a separate rule for child-process elevation, deny child processes or allow all child processes to inherit elevation. Microsoft warns that allowing all child processes to run elevated causes rule evaluation—including deny rules—to be skipped for those child processes.

That is not a minor configuration option. It is a potential elevation boundary.

Any EPM evaluation should therefore test whether an approved application can launch:

• cmd.exe.
• PowerShell.
• script interpreters.
• package managers.
• installers.
• debuggers.
• administrative consoles; or
• another general-purpose executable.

An elevation rule that appears narrow at the parent-process level can become broad if unrestricted child processes inherit the elevated context.

macOS: administrator status and TCC are separate controls

On macOS, local administrator membership is only one part of the access model.

Transparency, Consent and Control govern application access to privacy-sensitive resources such as the camera, microphone, screen recording and Full Disk Access. MITRE tracks TCC Manipulation separately as T1548.006. It also tracks setuid and setgid abuse under T1548.001.

This means a macOS programme must separately govern:

• local administrator membership.
• privileged execution.
• TCC and privacy permissions.
• MDM-delivered privacy preferences.
• sudo.
• setuid and setgid.
• launch agents and daemons.
• application signing and notarisation; and
• writable application and library paths.

Removing administrator status does not automatically revoke every privacy permission previously granted to an application. Conversely, granting an application with TCC permission does not necessarily make the user a local administrator.

The two controls must be designed and reviewed separately.

Linux: sudoers are only part of the surface

On Linux, the privilege surface includes:

• sudo and sudoers.
• password less rules.
• cached sudo authentication.
• setuid and setgid.
• Linux capabilities.
• polkit.
• service managers such as systemd.
• writable service and executable paths.
• kernel modules; and
• mandatory access controls such as SELinux or AppArmor.

MITRE’s T1548.003 guidance specifically addresses sudoers, password requirements and the timestamp_timeout setting.

The 2025 sudo vulnerability CVE-2025-32463 demonstrates why configuration control alone is insufficient. The flaw allowed a local attacker to abuse the --chroot option to execute arbitrary commands as root even when the attacker was not authorised for those commands in sudoers. The issue affected sudo from 1.9.14 through 1.9.17 and was fixed in 1.9.17p1. CISA added it to the Known Exploited Vulnerabilities Catalog on September 29, 2025.

The correct response is not to abandon sudo governance. It is to combine privilege policy with vulnerability management and operating-system hardening.

Cross-platform coverage is an architecture requirement

Microsoft currently documents Intune Endpoint Privilege Management as applying to Windows. Its elevation rules support .exe, .msi and .ps1 files, and Microsoft states that the capability requires additional EPM-specific licensing.

That does not make it an unsuitable product for every organisation. It means that organisations with material Linux or macOS estates must decide whether they will:

• operate separate endpoint-privilege tools and policy models.
• accept inconsistent privilege governance across platforms; or
• Select an EPM platform designed to manage Windows, Linux and macOS centrally.

The evaluation should not stop at a “supports macOS” or “supports Linux” checkbox. Architects should test which native control surfaces are governed on each platform.

Where least privilege alone stops helping

A credible EPM architecture must state clearly what EPM does not replace.

1. Local privilege-escalation vulnerabilities

CVE-2025-24990 affected the third-party Agere modem driver that shipped with supported Windows operating systems. The vulnerability involved an untrusted pointer deference and could allow a local attacker with low privileges to obtain elevated authority. Microsoft removed the affected ltmdm64.sys driver through October 2025 cumulative update, and CISA added the vulnerability to its KEV Catalog on October 14, 2025.
An elevation workflow cannot patch a vulnerable kernel driver.

The relevant controls include:

• applying for the vendor update.
• removing obsolete driver dependencies.
• enabling vulnerable driver protections.
• restricting driver installation.
• using application and execution control; and
• monitoring driver-load activity.

EPM remains valuable because it removes the attacker’s ordinary route to administration. But it cannot guarantee that no software vulnerability will provide an alternative route.

2. DLL and library hijacking

Under T1574.001, an attacker may place or substitute a malicious DLL so that a legitimate application loads it. If the legitimate process runs at a higher privilege level, the attacker-controlled DLL can inherit that level.

The corresponding controls include:

• restricting access to application and library paths.
• enabling safe library-loading behaviour.
• restricting remote DLL loading.
• allow listing trusted libraries.
• updating vulnerable applications.
• detecting unexpected modules loaded from non-standard locations; and
• monitoring file and registry changes.

MITRE maps T1574.001 to Restrict Library Loading and Update Software. CIS Safeguard 2.6 separately calls for allowing only authorised .dll, .ocx and .so libraries to load into system processes.
EPM may reduce the number of processes that run elevated, thereby reducing the value of the hijack. It does not replace library control.

3. User-level data access

A standard user may still have legitimate access to commercially sensitive files, browser sessions, collaboration platforms, source code or customer information.

Removing administrator rights does not revoke the user’s authorised business access.

Identity governance, data-loss prevention, information protection, browser security and behaviour analytics remain necessary.

4. Social engineering and approval abuse

A technically correct elevation workflow can still fail if:

• users routinely approve prompts without understanding them.
• support personnel approve requests under SLA pressure.
• business justifications are not reviewed.
• emergency codes are shared.
• exceptions never expire; or
• The requester and approver are effectively the same control point.

The workflow must treat elevation as a security decision, not merely a help-desk transaction.

Why least-privilege programmes fail after deployment

The most common rollout failure is not that least privilege is conceptually wrong.

It is that the organisation removes administrator rights before it understands how privileged work is performed.

Rules are often built from:

• application inventories.
• interviews with a few administrators.
• assumptions about job titles.
• known help-desk tickets; or
• a short pilot that covers only routine weekly work.

Those sources miss infrequent but legitimate activity such as:

• monthly finance reconciliation.
• quarterly reporting.
• certificate renewal.
• vendor diagnostics.
• software upgrades.
• emergency recovery.
• hardware configuration.
• developer toolchain changes; and
• annual audit or compliance utilities.

Use audit data before enforcement

A practical rollout should begin in observation mode.

A 30-day period is a reasonable minimum starting point, but it should not be treated as a universal standard. The observation window should cover the organisation’s actual business cycle. Teams with monthly, quarterly or seasonal administrative activity may need a longer period or a continuing audit population.

During observation, capture:

• user and device identity.
• operating system.
• executable or script.
• publisher and certificate.
• file hash and version.
• file path.
• command-line arguments.
• parent and child processes.
• requested privilege level.
• network connectivity state.
• request reason.
• approval path; and
• resulting action.

Do not create one rule for every observed event. Classify the events into policy patterns.

Build policy by persona and task

Useful policy personas may include:

• ordinary business users.
• developers.
• IT support.
• infrastructure administrators.
• security operations.
• finance and audit teams.
• branch or field personnel.
• remote and intermittently connected users; and
• Third-party support engineers.

Within each persona, classify activity into:

• Denied: The action should never receive elevation.
• Pre-approved: A tightly identified and low-risk application may elevate automatically or with user confirmation.
• Justified: The user must provide a business reason or reauthenticate.
• Support-approved: An authorised reviewer must approve the specific request.
• Emergency: A time-limited break-glass process applies with enhanced evidence and review.
• Unknown: The request is blocked or contained until engineering analysis is complete.

Microsoft’s own guidance recommends strong rule identifiers such as hashes, certificates and signed file properties. It warns against relying only on file names and advises using paths that standard users cannot modify. Microsoft also recommends using automatic elevation sparingly and only for trusted, business-critical files.

These are vendor-neutral rule-design principles.

Do not create a new standing-privilege problem through exceptions

The exception register can quietly become the replacement for the local Administrators group.

Every exception should therefore have:

• a named business owner.
• a technical owner.
• a defined scope.
• an approval record.
• a start date.
• an expiry date.
• a review frequency.
• a documented reason.
• compensating controls; and
• automatic revocation wherever possible.

Permanent exceptions should be rare and periodically challenged.

“Approved once” must not silently become “approved forever.”

Metrics that engineering teams and executives can both use

A successful EPM programme should report both security outcomes and operational impact.

Security measures

• Percentage of endpoints with no standing local administrator membership.
• Number of permanent administrator assignments removed.
• Percentage of privileged activity broke through EPM or PAM.
• Number and median age of active exceptions.
• Number of elevation attempts denied by policy.
• Number of elevations involving an unknown application, unsigned file or user-writable path.
• Number of rules permitting unrestricted elevated child processes.
• Percentage of privileged actions with complete requester, approver, purpose and duration evidence.

Operational measures

• Percentage of legitimate elevation requests resolved through an existing rule.
• Median time to complete an approved elevated task.
• Support tickets for 100 managed endpoints.
• Percentage of requests requiring manual approval.
• Percentage of manual requests subsequently converted into safe policy.
• User-impact incidents caused by missing or incorrect rules.
• Policy coverage across Windows, Linux and macOS.
• Number of elevation rules retired because the underlying application or workflow no longer exists.

The objective is not to drive elevation requests to zero.

The objective is to ensure that every necessary elevated action is intentional, narrowly scoped, time-bound and attributable.

The endpoint control stack architects should design

A mature endpoint-security architecture needs complementary layers.

No single row replaces the others.

How ARCON | Endpoint Privilege Management fits this model

ARCON documents its EPM platform as providing centralised governance for Windows, Linux and macOS from one administrative console.

Its documented capabilities include:

• just-in-time privilege elevation.
• Privileged Elevation and Delegation Management.
• Temporary elevated access for defined tasks.
• application allow listing and blocklisting.
• File Integrity Monitoring with rollbacks where required.
• Online and offline elevation workflows.
• an independent workflow for users outside the organizational network.
• audit trails, reporting and alerting.
• behavioural analytics for privileged endpoint activity; and
• integration with ARCON | Privileged Access Management.

These capabilities should be validated against the organisation’s actual use cases during evaluation.

The buying decision should not be based on the longest feature list. It should be based on whether the product can enforce the required privilege model without replacing standing administrator rights with broad, unsafe elevation rules.

What to test in an ARCON EPM proof of value

Use a representative pilot rather than a controlled demonstration built around a few well-known installers.

Include:

• Windows, Linux and macOS endpoints.
• ordinary users and technical users.
• online, remote and intermittently connected devices.
• predictable and unpredictable elevation requests.
• signed and unsigned applications.
• scripts and command-line tools.
• applications that create child processes.
• software running from user-writable locations.
• emergency access.
• expired requests and exceptions; and
• integration with PAM, SIEM, service desk and identity systems.

Measure whether the pilot can:

• remove standing administrator rights.
• preserve legitimate productivity.
• identify applications and workflows that genuinely require elevation.
• prevent broad-processed child inheritance.
• govern offline elevation.
• automatically revoke temporary authority.
• provide complete audit evidence; and
• create consistent policies across operating systems.

A practical 90-day implementation sequence

Days 1–30: Observe

Deploy to a representative cohort in audit or discovery mode.

Capture elevation behaviour, identify standing administrators, classify applications and map business personas.
Do not remove administrator rights from the entire cohort immediately.

Days 31–60: Control

Create rules based on observed activity.

Start with:

• tightly defined pre-approved applications.
• denied high-risk tools.
• support-approved unknown requests.
• time-bound emergency access; and
• explicit handling of child processes and command-line arguments.

Remove standing administrator rights from a limited group and measure disruption.

Days 61–90: Expand

Correct false positives and missing workflows.

Convert repeated legitimate requests into tightly scoped policy, retire unnecessary exceptions and extend the programme to additional personas and operating systems.

Present the results using both security and operational measures.

Questions for the architecture review

Before selecting or expanding an EPM platform, ask:

• Does the product remove local administrator membership or merely add another elevation mechanism?
• Can it elevate an application or task without elevating the user’s entire session?
• How are child processes controlled?
• Can rules include hashes, certificates, versions, paths and command-line arguments?
• Can users modify the location from which an approved application runs?
• How are unknown, unsigned and user-writable-path applications handled?
• How are Windows, Linux and macOS governed differently?
• Can remote or offline users obtain controlled, time-bound elevation?
• Are requester, approver, justification, duration and outcome captured?
• Do exceptions expire automatically?
• How does the platform integrate with PAM, identity, service desk, SIEM and EDR?
• Can the organisation prove that temporary privilege was revoked?

The engineering decision

Removing standing administrator rights is not a claim that every endpoint attack will be stopped.

It is a deliberate architectural decision to ensure that compromise of an ordinary user, process or application doesnot automatically become compromised of the operating system.

The strongest EPM programme therefore does four things:

• removes unnecessary standing authority.
• provides controlled elevation for legitimate work.
• pairs elevation with application, script and library controls; and
• produces evidence that every privileged action was authorised, limited and revoked.

That is the standard an endpoint privilege platform should be evaluated against.