Abuse of Service Permissions to Hide Services Via Set-Service - PS

About the rule

Rule Type

Standard

Rule Description

Attackers can abuse Windows service permissions by using PowerShell’s Set-Service cmdlet to alter a service’s Security Descriptor (SDDL) and make the service “hidden” from common utilities (sc.exe, Get-Service, standard administrative tools), thereby evading detection in the system.

Severity

Trouble

Rule journey

Attack chain scenario

Initial access (through phishing) → Execution → Defense Evasion → Persistence → Privilege Escalation → Command and Control → Impact

Impact

• The attacker use PowerShell 7+ (Set-Service with -SecurityDescriptorSddl), attacker supplies a custom SDDL string to a service, effectively hiding it from users and some tools.
• The malicious or hijacked service runs in the background, unnoticed by most admin enumeration tools (e.g., Get-Service, sc.exe), and can start at boot or on demand.
• Attacker reverts the SDDL, remove traces for cleanup.

Rule Requirement

Prerequisites

• Log in to the Group Policy Management Console (GPMC) with domain admin credentials.
• In the Group Policy Management Editor, go to Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Powershell and enable Turn on Module Logging.
• In the Options pane, click on Show, and in the Module Name, enter * to record all modules, and press OK.
• In the Group Policy Management Editor, go to Computer Configuration and Turn on PowerShell Script Block Logging.
• Create a new registry key "Microsoft-Windows-Powershell/Operational" in the directory "Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\".

Criteria

Detection

Execution Mode

realtime

Log Sources

Windows

MITRE ATT&CK

Defense Evasion: Hijack Execution Flow - Services Registry Permissions Weakness (T1574.011), Persistence: Hijack Execution Flow - Services Registry Permissions Weakness (T1574.011), Privilege Escalation: Hijack Execution Flow - Services Registry Permissions Weakness (T1574.011)

Security Standards

Enabling this rule will help you meet the security standard's requirements listed below:

PR.AA-05: Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties

Security administrators ensure to draft and implement strict privilege permission for critical operations of certification and the usage of PowerShell scripts. Leverage IAM and SIEM solutions to ensure access permission and authorizations and regular auditing practices.

DE.CM-01: Networks and network services are monitored to find potentially adverse events.

Security administrators have to continuously monitor all the network and its services in real-time using SIEM tools and identify the unusual behavior during PowerShell scripting. Enforce the policies on the web traffic to ensure the network security.

Author

Nasreddine Bencherchali (Nextron Systems)

Future actions

Known False Positives

False positive detections for abuse of service permissions via Set-Service in PowerShell are rare but can occur during legitimate administrative activities such as automated scripts or DevOps tools applying standard SDDL configurations may unintentionally trigger alerts, even though the actions are part of routine system management.

Next Steps

When this rule is triggered, the following measures can be implemented:

1. Identification: Identify the event and check if the flagged incident is new or part of an existing one.
2. Analysis: Analyze the impact and extent of the incident to comprehend the severity of the attack using the Incident Workbench.
3. Response: Respond promptly by initiating an automated workflow to interrupt the network connections and kill or terminate the malicious process.
4. Reconfiguration: Update the network policies, port configurations, and continuously monitor traffic trends in the network.

Mitigation