Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
The table of contents is too big for display.
Diff view
Diff view
  •  
  •  
  •  
Original file line number Diff line number Diff line change
@@ -0,0 +1,140 @@
[[prebuilt-rule-8-19-36-access-control-list-modification-via-setfacl]]
=== Access Control List Modification via setfacl

This rule detects Linux Access Control List (ACL) modification via the setfacl command. Attackers may use the setfacl utility to modify file and directory permissions in order to evade detection and maintain persistence on a compromised system.

*Rule type*: eql

*Rule indices*:

* auditbeat-*
* endgame-*
* logs-auditd_manager.auditd-*
* logs-crowdstrike.fdr*
* logs-endpoint.events.process*
* logs-sentinel_one_cloud_funnel.*

*Severity*: low

*Risk score*: 21

*Runs every*: 5m

*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)

*Maximum alerts per execution*: 100

*References*:

* https://www.uptycs.com/blog/threat-research-report-team/evasive-techniques-used-by-malicious-linux-shell-scripts

*Tags*:

* Domain: Endpoint
* OS: Linux
* Use Case: Threat Detection
* Tactic: Defense Evasion
* Data Source: Elastic Defend
* Data Source: Elastic Endgame
* Data Source: Auditd Manager
* Data Source: Crowdstrike
* Data Source: SentinelOne
* Resources: Investigation Guide
* Noise: High
* Performance: Normal
* Profile: Aggressive
* Rule Type: Event Correlation (EQL)
* Platform: Linux

*Version*: 110

*Rule authors*:

* Elastic

*Rule license*: Elastic License v2


==== Investigation guide



*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 Access Control List Modification via setfacl*


Access Control Lists (ACLs) in Linux enhance file permission management by allowing more granular access control. The `setfacl` command modifies these ACLs, potentially altering who can access or modify files. Adversaries may exploit `setfacl` to stealthily change permissions, evading detection and maintaining persistence. The detection rule identifies suspicious `setfacl` executions, excluding benign patterns, to flag potential misuse.


*Possible investigation steps*


- Review the process details to confirm the execution of the setfacl command, focusing on the process.name and event.type fields to ensure the alert is valid.
- Examine the process.command_line to understand the specific ACL modifications attempted and identify any unusual or unauthorized changes.
- Investigate the user account associated with the process execution to determine if the action aligns with their typical behavior or role.
- Check the process's parent process to identify how the setfacl command was initiated and assess if it was part of a legitimate workflow or a potential compromise.
- Correlate the event with other security logs or alerts from the same host to identify any related suspicious activities or patterns that might indicate a broader attack.


*False positive analysis*


- Routine system maintenance tasks may trigger the rule if they involve legitimate use of setfacl. To manage this, identify and document regular maintenance scripts or processes that use setfacl and create exceptions for these specific command lines.
- Backup operations that restore ACLs using setfacl can be mistaken for suspicious activity. Exclude these by adding exceptions for command lines that match known backup procedures, such as those using the --restore option.
- Automated log management tools might use setfacl to manage permissions on log directories like /var/log/journal/. To prevent false positives, exclude these specific directory paths from triggering the rule.
- Custom applications or services that require dynamic permission changes using setfacl could be flagged. Review these applications and, if deemed safe, add their specific command patterns to the exception list to avoid unnecessary alerts.


*Response and remediation*


- Immediately isolate the affected system from the network to prevent further unauthorized access or changes.
- Review the process execution logs to identify any unauthorized users or processes that executed the `setfacl` command.
- Revert any unauthorized ACL changes by restoring the original file permissions from a known good backup or configuration.
- Conduct a thorough scan of the system for any additional signs of compromise, such as unauthorized user accounts or unexpected processes.
- Update and patch the system to address any vulnerabilities that may have been exploited to gain access.
- Implement stricter access controls and monitoring on critical systems to detect and prevent unauthorized ACL modifications in the future.
- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.

==== Rule query


[source, js]
----------------------------------
process where host.os.type == "linux" and event.type == "start" and
event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
process.name == "setfacl" and
not (
?process.parent.executable in (
"/opt/puppetlabs/puppet/bin/ruby", "/usr/libexec/dirsrv/ds_systemd_ask_password_acl", "/usr/lib/systemd/systemd-udevd",
"/usr/bin/udevadm", "/usr/sbin/ds_systemd_ask_password_acl", "/usr/bin/su", "/bin/su"
) or
process.command_line == "/bin/setfacl --restore=-" or
process.args == "/var/log/journal/" or
process.parent.name in ("stats.pl", "perl", "find") or
?process.parent.command_line like~ "*ansible*" or
?process.parent.args == "/opt/audit-log-acl.sh"
)

----------------------------------

*Framework*: MITRE ATT&CK^TM^

* Tactic:
** Name: Defense Evasion
** ID: TA0005
** Reference URL: https://attack.mitre.org/tactics/TA0005/
* Technique:
** Name: File and Directory Permissions Modification
** ID: T1222
** Reference URL: https://attack.mitre.org/techniques/T1222/
* Sub-technique:
** Name: Linux and Mac File and Directory Permissions Modification
** ID: T1222.002
** Reference URL: https://attack.mitre.org/techniques/T1222/002/
Original file line number Diff line number Diff line change
@@ -0,0 +1,181 @@
[[prebuilt-rule-8-19-36-access-to-a-sensitive-ldap-attribute]]
=== Access to a Sensitive LDAP Attribute

Identify access to sensitive Active Directory object attributes that contains credentials and decryption keys such as ms-PKI-DPAPIMasterKeys, ms-PKI-AccountCredentials, and msPKI-CredentialRoamingTokens.

*Rule type*: eql

*Rule indices*:

* logs-system.security*
* logs-windows.forwarded*
* winlogbeat-*

*Severity*: medium

*Risk score*: 47

*Runs every*: 5m

*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)

*Maximum alerts per execution*: 100

*References*:

* https://cloud.google.com/blog/topics/threat-intelligence/apt29-windows-credential-roaming
* https://social.technet.microsoft.com/wiki/contents/articles/11483.windows-credential-roaming.aspx
* https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4662

*Tags*:

* Domain: Endpoint
* OS: Windows
* Use Case: Threat Detection
* Tactic: Credential Access
* Tactic: Privilege Escalation
* Use Case: Active Directory Monitoring
* Data Source: Active Directory
* Data Source: Windows Security Event Logs
* Resources: Investigation Guide
* Noise: High
* Performance: Normal
* Profile: Aggressive
* Rule Type: Event Correlation (EQL)
* Platform: Windows

*Version*: 122

*Rule authors*:

* Elastic

*Rule license*: Elastic License v2


==== Investigation guide



*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 Access to a Sensitive LDAP Attribute*


LDAP (Lightweight Directory Access Protocol) is crucial for accessing and managing directory information in Active Directory environments. Adversaries may exploit LDAP to access sensitive attributes like passwords and decryption keys, facilitating credential theft or privilege escalation. The detection rule identifies unauthorized access attempts by monitoring specific event codes and attribute identifiers, excluding benign activities to reduce noise, thus highlighting potential security threats.


*Possible investigation steps*


- Review the event logs for event code 4662 to identify the specific user or process attempting to access the sensitive LDAP attributes.
- Check the winlog.event_data.SubjectUserSid to determine the identity of the user or service account involved in the access attempt, excluding the well-known SID S-1-5-18 (Local System).
- Analyze the winlog.event_data.Properties field to confirm which sensitive attribute was accessed, such as ms-PKI-DPAPIMasterKeys, ms-PKI-AccountCredentials, or msPKI-CredentialRoamingTokens.
- Investigate the context of the access attempt by correlating the event with other logs or alerts around the same timestamp to identify any suspicious patterns or activities.
- Verify the legitimacy of the access by checking if the user or process has a valid reason or permission to access the sensitive attributes, considering the organization's access control policies.
- Assess the potential impact of the access attempt on the organization's security posture, focusing on credential theft or privilege escalation risks.
- Document findings and, if necessary, escalate the incident to the appropriate security team for further action or remediation.


*False positive analysis*


- Access by legitimate administrative accounts: Regular access by system administrators to sensitive LDAP attributes can trigger alerts. To manage this, create exceptions for known administrative accounts by excluding their SIDs from the detection rule.
- Scheduled system processes: Automated tasks or system processes that require access to certain LDAP attributes may cause false positives. Identify these processes and exclude their specific event codes or AccessMasks if they are consistently benign.
- Service accounts: Service accounts that perform routine directory operations might access sensitive attributes as part of their normal function. Exclude these accounts by adding their SIDs to the exception list to prevent unnecessary alerts.
- Monitoring tools: Security or monitoring tools that scan directory attributes for compliance or auditing purposes can generate false positives. Whitelist these tools by excluding their event sources or specific actions from the detection criteria.


*Response and remediation*


- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
- Conduct a thorough review of the access logs to identify any unauthorized users or systems that accessed the sensitive LDAP attributes.
- Reset passwords and revoke any potentially compromised credentials associated with the affected accounts, focusing on those with access to sensitive attributes.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach.
- Implement additional monitoring on the affected systems and accounts to detect any further suspicious activities or attempts to access sensitive LDAP attributes.
- Review and update access controls and permissions for sensitive LDAP attributes to ensure they are restricted to only necessary personnel.
- Conduct a post-incident analysis to identify any gaps in security controls and update policies or procedures to prevent similar incidents in the future.

==== Setup



*Setup*


Audit Directory Service Access must be enabled to generate the events used by this rule.
Setup instructions: https://ela.st/audit-directory-service-access


==== Rule query


[source, js]
----------------------------------
any where host.os.type == "windows" and event.code == "4662" and

winlog.event_data.AccessMask in ("0x10") and

not winlog.event_data.SubjectUserSid : "S-1-5-18" and

winlog.event_data.Properties : (
/* ms-PKI-AccountCredentials */
"*b8dfa744-31dc-4ef1-ac7c-84baf7ef9da7*",

/* ms-PKI-DPAPIMasterKeys */
"*b3f93023-9239-4f7c-b99c-6745d87adbc2*",

/* msPKI-CredentialRoamingTokens */
"*b7ff5a38-0818-42b0-8110-d3d154c97f24*"
)

----------------------------------

*Framework*: MITRE ATT&CK^TM^

* Tactic:
** Name: Credential Access
** ID: TA0006
** Reference URL: https://attack.mitre.org/tactics/TA0006/
* Technique:
** Name: OS Credential Dumping
** ID: T1003
** Reference URL: https://attack.mitre.org/techniques/T1003/
* Technique:
** Name: Unsecured Credentials
** ID: T1552
** Reference URL: https://attack.mitre.org/techniques/T1552/
* Sub-technique:
** Name: Private Keys
** ID: T1552.004
** Reference URL: https://attack.mitre.org/techniques/T1552/004/
* Technique:
** Name: Steal or Forge Authentication Certificates
** ID: T1649
** Reference URL: https://attack.mitre.org/techniques/T1649/
* Tactic:
** Name: Privilege Escalation
** ID: TA0004
** Reference URL: https://attack.mitre.org/tactics/TA0004/
* Technique:
** Name: Valid Accounts
** ID: T1078
** Reference URL: https://attack.mitre.org/techniques/T1078/
* Sub-technique:
** Name: Domain Accounts
** ID: T1078.002
** Reference URL: https://attack.mitre.org/techniques/T1078/002/
* Tactic:
** Name: Collection
** ID: TA0009
** Reference URL: https://attack.mitre.org/tactics/TA0009/
* Technique:
** Name: Data from Information Repositories
** ID: T1213
** Reference URL: https://attack.mitre.org/techniques/T1213/
Loading
Loading