WebServer Access Logs Deleted

 1[metadata]
 2creation_date = "2020/11/03"
 3integration = ["endpoint", "windows"]
 4maturity = "production"
 5updated_date = "2025/03/20"
 6
 7[rule]
 8author = ["Elastic"]
 9description = """
10Identifies the deletion of WebServer access logs. This may indicate an attempt to evade detection or destroy forensic
11evidence on a system.
12"""
13from = "now-9m"
14index = ["auditbeat-*", "winlogbeat-*", "logs-endpoint.events.*", "logs-windows.sysmon_operational-*"]
15language = "eql"
16license = "Elastic License v2"
17name = "WebServer Access Logs Deleted"
18note = """## Triage and analysis
19
20> **Disclaimer**:
21> 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.
22
23### Investigating WebServer Access Logs Deleted
24
25Web server access logs are crucial for monitoring and analyzing web traffic, providing insights into user activity and potential security incidents. Adversaries may delete these logs to cover their tracks, hindering forensic investigations. The detection rule identifies log deletions across various operating systems by monitoring specific file paths, signaling potential attempts at evasion or evidence destruction.
26
27### Possible investigation steps
28
29- Review the specific file path where the deletion event was detected to determine which web server's logs were affected, using the file.path field from the alert.
30- Check for any recent access or modification events on the affected web server to identify potential unauthorized access or suspicious activity prior to the log deletion.
31- Investigate user accounts and processes that had access to the deleted log files around the time of the deletion event to identify potential malicious actors or compromised accounts.
32- Correlate the log deletion event with other security alerts or anomalies in the same timeframe to identify patterns or related incidents.
33- Examine backup logs or alternative logging mechanisms, if available, to recover deleted information and assess the impact of the log deletion on forensic capabilities.
34
35### False positive analysis
36
37- Routine log rotation or maintenance scripts may delete old web server logs. To handle this, identify and exclude these scheduled tasks from triggering alerts by specifying their execution times or associated process names.
38- Automated backup processes that move or delete logs after archiving can trigger false positives. Exclude these processes by adding exceptions for the backup software or scripts used.
39- Development or testing environments where logs are frequently cleared to reset the environment can cause alerts. Consider excluding these environments by specifying their IP addresses or hostnames.
40- System administrators manually deleting logs as part of regular maintenance can be mistaken for malicious activity. Implement a policy to log and approve such actions, and exclude these approved activities from detection.
41- Temporary log deletions during server migrations or upgrades might trigger alerts. Document these events and create temporary exceptions during the migration period.
42
43### Response and remediation
44
45- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
46- Conduct a thorough review of recent user activity and system changes to identify any unauthorized access or modifications that may have led to the log deletion.
47- Restore the deleted web server access logs from backups, if available, to aid in further forensic analysis and investigation.
48- Implement enhanced monitoring on the affected system to detect any further attempts at log deletion or other suspicious activities.
49- Review and tighten access controls and permissions on log files to ensure only authorized personnel can modify or delete them.
50- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised.
51- Document the incident, including all actions taken, and update incident response plans to improve future detection and response capabilities."""
52risk_score = 47
53rule_id = "665e7a4f-c58e-4fc6-bc83-87a7572670ac"
54setup = """## Setup
55
56If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2,
57events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2.
58Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate
59`event.ingested` to @timestamp.
60For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html
61"""
62severity = "medium"
63tags = [
64    "Domain: Endpoint",
65    "OS: Linux",
66    "OS: Windows",
67    "OS: macOS",
68    "Use Case: Threat Detection",
69    "Tactic: Defense Evasion",
70    "Data Source: Elastic Defend",
71    "Data Source: Sysmon",
72    "Resources: Investigation Guide",
73]
74timestamp_override = "event.ingested"
75type = "eql"
76
77query = '''
78file where event.type == "deletion" and
79  file.path : ("C:\\inetpub\\logs\\LogFiles\\*.log",
80               "/var/log/apache*/access.log",
81               "/etc/httpd/logs/access_log",
82               "/var/log/httpd/access_log",
83               "/var/www/*/logs/access.log")
84'''
85
86
87[[rule.threat]]
88framework = "MITRE ATT&CK"
89[[rule.threat.technique]]
90id = "T1070"
91name = "Indicator Removal"
92reference = "https://attack.mitre.org/techniques/T1070/"
93
94
95[rule.threat.tactic]
96id = "TA0005"
97name = "Defense Evasion"
98reference = "https://attack.mitre.org/tactics/TA0005/"