Service DACL Modification via sc.exe

Identifies DACL modifications to deny access to a service, making it unstoppable, or hide it from system and users.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2024/07/16"
  3integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defender", "crowdstrike"]
  4maturity = "production"
  5min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
  6min_stack_version = "8.14.0"
  7updated_date = "2025/01/10"
  8
  9[rule]
 10author = ["Elastic"]
 11description = """
 12Identifies DACL modifications to deny access to a service, making it unstoppable, or hide it from system and users.
 13"""
 14from = "now-9m"
 15index = ["winlogbeat-*", "logs-endpoint.events.process-*", "logs-windows.sysmon_operational-*", "endgame-*", "logs-sentinel_one_cloud_funnel.*", "logs-m365_defender.event-*", "logs-crowdstrike.fdr*"]
 16language = "eql"
 17license = "Elastic License v2"
 18name = "Service DACL Modification via sc.exe"
 19references = [
 20  "https://blogs.jpcert.or.jp/en/2024/07/mirrorface-attack-against-japanese-organisations.html",
 21  "https://github.com/SigmaHQ/sigma/blob/master/rules/windows/process_creation/proc_creation_win_sc_sdset_deny_service_access.yml",
 22  "https://learn.microsoft.com/en-us/windows/win32/secauthz/sid-strings",
 23  "https://www.sans.org/blog/red-team-tactics-hiding-windows-services/"
 24]
 25risk_score = 47
 26rule_id = "5188c68e-d3de-4e96-994d-9e242269446f"
 27severity = "medium"
 28tags = [
 29    "Domain: Endpoint",
 30    "OS: Windows",
 31    "Use Case: Threat Detection",
 32    "Tactic: Defense Evasion",
 33    "Resources: Investigation Guide",
 34    "Data Source: Elastic Endgame",
 35    "Data Source: Elastic Defend",
 36    "Data Source: Sysmon",
 37    "Data Source: SentinelOne",
 38    "Data Source: Microsoft Defender for Endpoint",
 39    "Data Source: Crowdstrike"
 40]
 41timestamp_override = "event.ingested"
 42type = "eql"
 43
 44query = '''
 45process where host.os.type == "windows" and event.type == "start" and
 46  (process.name : "sc.exe" or ?process.pe.original_file_name : "sc.exe") and
 47  process.args : "sdset" and process.args : "*D;*" and
 48  process.args : ("*;IU*", "*;SU*", "*;BA*", "*;SY*", "*;WD*")
 49'''
 50note = """## Triage and analysis
 51
 52> **Disclaimer**:
 53> 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.
 54
 55### Investigating Service DACL Modification via sc.exe
 56
 57The `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.
 58
 59### Possible investigation steps
 60
 61- Review the process execution details to confirm the presence of "sc.exe" with the "sdset" argument, indicating a potential DACL modification attempt.
 62- 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.
 63- Check the process execution timeline to determine if this activity coincides with other suspicious behavior or unauthorized access attempts.
 64- 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.
 65- Correlate this event with other security alerts or logs from data sources like Elastic Endgame, Sysmon, or Microsoft Defender for Endpoint to identify potential patterns or related incidents.
 66- Assess the impact on the affected service by verifying its current state and functionality, ensuring it is not hidden or unmanageable.
 67- If necessary, consult with system administrators to understand the legitimate need for such modifications and confirm if the activity was authorized.
 68
 69### False positive analysis
 70
 71- 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.
 72- 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.
 73- 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.
 74- 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.
 75- 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.
 76
 77### Response and remediation
 78
 79- Immediately isolate the affected system from the network to prevent further unauthorized access or changes to service permissions.
 80- Terminate any suspicious processes related to sc.exe that are actively modifying service DACLs to stop ongoing malicious activity.
 81- Restore the original DACL settings for the affected services using a known good configuration or backup to ensure proper access control is reinstated.
 82- Conduct a thorough review of user accounts and permissions to identify and revoke any unauthorized access that may have been granted during the attack.
 83- 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.
 84- 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.
 85- 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."""
 86
 87
 88[[rule.threat]]
 89framework = "MITRE ATT&CK"
 90[[rule.threat.technique]]
 91id = "T1564"
 92name = "Hide Artifacts"
 93reference = "https://attack.mitre.org/techniques/T1564/"
 94
 95
 96
 97[rule.threat.tactic]
 98id = "TA0005"
 99name = "Defense Evasion"
100reference = "https://attack.mitre.org/tactics/TA0005/"
101
102[[rule.threat]]
103framework = "MITRE ATT&CK"
104[[rule.threat.technique]]
105id = "T1543"
106name = "Create or Modify System Process"
107reference = "https://attack.mitre.org/techniques/T1543/"
108[[rule.threat.technique.subtechnique]]
109id = "T1543.003"
110name = "Windows Service"
111reference = "https://attack.mitre.org/techniques/T1543/003/"
112
113
114
115[rule.threat.tactic]
116id = "TA0003"
117name = "Persistence"
118reference = "https://attack.mitre.org/tactics/TA0003/"

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 for Endpoint 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

Related rules

to-top