Service DACL Modification via sc.exe
ELASTIC detection rule by Elastic · Elastic License v2
Identifies DACL modifications to deny access to a service, making it unstoppable, or hide it from system and users.
[metadata]
creation_date = "2024/07/16"
integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defender", "crowdstrike"]
maturity = "production"
updated_date = "2026/05/04"
[rule]
author = ["Elastic"]
description = "Identifies DACL modifications to deny access to a service, making it unstoppable, or hide it from system and users.\n"
from = "now-9m"
index = [
"winlogbeat-*",
"logs-endpoint.events.process-*",
"logs-windows.sysmon_operational-*",
"endgame-*",
"logs-sentinel_one_cloud_funnel.*",
"logs-m365_defender.event-*",
"logs-crowdstrike.fdr*",
]
language = "eql"
license = "Elastic License v2"
name = "Service DACL Modification via sc.exe"
note = """## Triage and analysis
> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
### Investigating Service DACL Modification via sc.exe
The `sc.exe` utility in Windows is used to manage services, including modifying their Discretionary Access Control Lists (DACLs). Adversaries may exploit this to alter service permissions, making them unmanageable or hidden. The detection rule identifies such modifications by monitoring for specific command patterns that indicate DACL changes, focusing on access denial to key user groups, thus flagging potential defense evasion attempts.
### Possible investigation steps
- Review the process execution details to confirm the presence of "sc.exe" with the "sdset" argument, indicating a potential DACL modification attempt.
- Examine the specific arguments used with "sc.exe" to identify which user groups (e.g., IU, SU, BA, SY, WD) were targeted for access denial.
- Check the process execution timeline to determine if this activity coincides with other suspicious behavior or unauthorized access attempts.
- Investigate the user account associated with the process execution to assess if it has the necessary privileges and if the activity aligns with their typical behavior.
- Correlate this event with other security alerts or logs from data sources like Elastic Endgame, Sysmon, or Microsoft Defender XDR to identify potential patterns or related incidents.
- Assess the impact on the affected service by verifying its current state and functionality, ensuring it is not hidden or unmanageable.
- If necessary, consult with system administrators to understand the legitimate need for such modifications and confirm if the activity was authorized.
### False positive analysis
- Routine administrative tasks using sc.exe to modify service permissions may trigger the rule. Review the context of the command and verify if it aligns with standard IT maintenance activities.
- Automated scripts or software deployment tools that adjust service DACLs for legitimate configuration purposes can cause false positives. Identify these scripts and consider excluding their specific command patterns from the rule.
- Security software updates or patches that modify service permissions as part of their installation process might be flagged. Confirm the legitimacy of the update and exclude the associated process arguments if necessary.
- Custom applications that require specific service permissions for functionality may inadvertently match the detection criteria. Validate the application's behavior and create exceptions for its known safe operations.
- Regular audits or compliance checks that involve service DACL modifications could be misinterpreted as malicious. Document these activities and adjust the rule to ignore them when performed by authorized personnel.
### Response and remediation
- Immediately isolate the affected system from the network to prevent further unauthorized access or changes to service permissions.
- Terminate any suspicious processes related to sc.exe that are actively modifying service DACLs to stop ongoing malicious activity.
- Restore the original DACL settings for the affected services using a known good configuration or backup to ensure proper access control is reinstated.
- Conduct a thorough review of user accounts and permissions to identify and revoke any unauthorized access that may have been granted during the attack.
- Implement additional monitoring on the affected system and similar systems to detect any further attempts to modify service DACLs, using enhanced logging and alerting mechanisms.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the attack is part of a larger campaign.
- Review and update endpoint protection policies to prevent similar threats in the future, ensuring that all systems are equipped with the latest security patches and configurations."""
references = [
"https://blogs.jpcert.or.jp/en/2024/07/mirrorface-attack-against-japanese-organisations.html",
"https://github.com/SigmaHQ/sigma/blob/master/rules/windows/process_creation/proc_creation_win_sc_sdset_deny_service_access.yml",
"https://learn.microsoft.com/en-us/windows/win32/secauthz/sid-strings",
"https://www.sans.org/blog/red-team-tactics-hiding-windows-services/",
]
risk_score = 47
rule_id = "5188c68e-d3de-4e96-994d-9e242269446f"
severity = "medium"
tags = [
"Domain: Endpoint",
"OS: Windows",
"Use Case: Threat Detection",
"Tactic: Defense Evasion",
"Resources: Investigation Guide",
"Data Source: Elastic Endgame",
"Data Source: Elastic Defend",
"Data Source: Sysmon",
"Data Source: SentinelOne",
"Data Source: Microsoft Defender XDR",
"Data Source: Crowdstrike",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type == "windows" and event.type == "start" and
(process.name : "sc.exe" or ?process.pe.original_file_name : "sc.exe") and
process.args : "sdset" and process.args : "*D;*" and
process.args : ("*;IU*", "*;SU*", "*;BA*", "*;SY*", "*;WD*")
'''
setup = """## Setup
This rule is designed for data generated by [Elastic Defend](https://www.elastic.co/security/endpoint-security), which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.
Setup instructions: https://ela.st/install-elastic-defend
### Additional data sources
This rule also supports the following third-party data sources. For setup instructions, refer to the links below:
- [CrowdStrike](https://ela.st/crowdstrike-integration)
- [Microsoft Defender XDR](https://ela.st/m365-defender)
- [SentinelOne Cloud Funnel](https://ela.st/sentinel-one-cloud-funnel)
- [Sysmon Event ID 1 - Process Creation](https://ela.st/sysmon-event-1-setup)
"""
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1564"
name = "Hide Artifacts"
reference = "https://attack.mitre.org/techniques/T1564/"
[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1543"
name = "Create or Modify System Process"
reference = "https://attack.mitre.org/techniques/T1543/"
[[rule.threat.technique.subtechnique]]
id = "T1543.003"
name = "Windows Service"
reference = "https://attack.mitre.org/techniques/T1543/003/"
[rule.threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"