Policy: Require Approval to Elevate a Specific RunDLL32 Control-Panel Action

This example shows a Privilege Elevation policy that targets a specific elevation scenario (a particular application/process) and requires approval before allowing that elevation to proceed. It also demonstrates how to allow only specific RunDLL32 command variants via an allowlist.

---

What this Policy Does

When a user attempts to elevate the targeted process on any in-scope endpoint, the policy:

• Matches the request based on user, machine, and application targeting

• Requires Approval before allowing the process to run with elevated privileges

• Does not require the user to acknowledge the notification (acknowledgement is disabled)

In addition, the policy includes an allowlist of commands associated with RunDLL32-style execution, limiting what control-panel style actions are allowed under this elevation path.

---

Why it Behaves this Way

This policy is narrowly scoped compared to “all elevations” policies:

• Enforced: The policy is active and will apply controls.

• Approval on success: When it matches, it triggers an approval workflow (Approval is the only required control in this example).

• All users: A wildcard user scope means any user can trigger the workflow (on in-scope endpoints).

• Multiple endpoints: The policy applies to more than one endpoint because machine targeting includes multiple machine identifiers.

• Specific application targeting: Instead of *, the application targeting points at a specific application identifier—so only that process (and its elevation attempt) is affected.

• Built-in checks: Standard checks are used (user, machine, file/app, date/time/day, certificate). With date/time/day/cert constraints left empty, the policy generally applies whenever the user/machine/app match.

• Command allowlist (Extension): The Extension.AllowCommands list acts as a guardrail for RunDLL32-style operations by allowing only the listed command patterns/entries (e.g., specific control panel applets or invocation styles).

---

What the User Experiences

• If they try to elevate the targeted RunDLL32-related action on an in-scope endpoint, they’ll be prompted to request approval.

• Once approved, the elevation proceeds only for the allowed command entries defined in the allowlist (helpful for reducing “living off the land” abuse while still permitting known-good administrative tasks).

• The notification does not require an explicit acknowledgement click.

---

Important Notes and Common Adjustments

• Tighten user scope: Replace the wildcard user targeting with a specific user/group set if only certain users should be eligible.

• Expand endpoint coverage: Add more endpoint identifiers (or use your preferred grouping/scoping approach) to broaden rollout.

• Add stronger controls: If desired, require MFA and/or justification alongside approval.

• Clarify the notification message: Ensure the message matches the policy mode and the controls actually required (this example requires approval only, but the message text references additional controls).

Example JSON

{
	"PolicyName": "_3_RunDLL32_Test",
	"PolicyType": "PrivilegeElevation",
	"PolicyId": "N0N1N2N3N4N5N6N7N8N9N",
	"Status": "enforce",
	"Actions": {
		"OnSuccess": {
			"Controls": [
				"APPROVAL"
			]
		},
		"OnFailure": {
			"Command": ""
		}
	},
	"NotificationMessage": "A policy has been set to monitor mode.  When this policy is enabled, [mfa, justification, request] will be required to run this process as an administrator.",
	"NotificationRequiresAcknowledge": false,
	"RiskLevel": 50,
	"Operator": "And",
	"Rules": [
		{
			"RuleName": "UserCheck",
			"ErrorMessage": "This user is not included in this policy",
			"RuleExpressionType": "BuiltInAction",
			"Expression": "CheckUser()"
		},
		{
			"RuleName": "MachineCheck",
			"ErrorMessage": "This Machine is not included in this policy",
			"RuleExpressionType": "BuiltInAction",
			"Expression": "CheckMachine()"
		},
		{
			"RuleName": "ApplicationCheck",
			"ErrorMessage": "This application is not included in this policy",
			"RuleExpressionType": "BuiltInAction",
			"Expression": "CheckFile(false)"
		},
		{
			"RuleName": "DateCheck",
			"ErrorMessage": "Current date is not covered by this policy",
			"RuleExpressionType": "BuiltInAction",
			"Expression": "CheckDate()"
		},
		{
			"RuleName": "TimeCheck",
			"ErrorMessage": "Current time is not covered by this policy",
			"RuleExpressionType": "BuiltInAction",
			"Expression": "CheckTime()"
		},
		{
			"RuleName": "DayCheck",
			"ErrorMessage": "Today is not included in this policy",
			"RuleExpressionType": "BuiltInAction",
			"Expression": "CheckDay()"
		},
		{
			"RuleName": "CertificateCheck",
			"ErrorMessage": "Certificate hash is not included in this policy",
			"RuleExpressionType": "BuiltInAction",
			"Expression": "CheckCertificate()"
		}
	],
	"UserCheck": [
		"*"
	],
	"MachineCheck": [
		"NSBYFNaHnhkIgVIazYhFXA",
		"-70-3Zk0vHv1fk5rq124XA"
	],
	"ApplicationCheck": [
		"htGTRrUF8zhAtnrahH8oHA"
	],
	"DayCheck": [],
	"DateCheck": [],
	"TimeCheck": [],
	"CertificationCheck": [],
	"Extension": {
		"AllowCommands": [
			"Control_RunDLLAsUser",
			"Control_RunDLL",
			"ncpa.cpl"
		]
	}
}