Security Misconfiguration (OWASP A02:2025): Detection with Wazuh SCA & FIM

Security misconfiguration moved from fifth to second place in the OWASP Top 10:2025. OWASP found some form of it in every tested application. It covers insecure settings anywhere in the stack: default passwords, exposed admin consoles, debug pages, directory listing, verbose error messages, XML parsers that process external entities and cloud storage open to the internet.

Attackers rarely need skill to exploit these weaknesses. Internet scanners constantly request paths like /.git/config and /.env. This article explains how misconfigurations are exploited, which evidence to look for, how to detect them with Wazuh Security Configuration Assessment, File Integrity Monitoring and custom access log rules, and how a SOC handles a hypothetical exposed secrets file.

This guide is part of the series OWASP Top 10 for SOC Analysts: Web Attack Detection and Investigation with Wazuh. For HTTP basics, how to read access logs and how Wazuh decodes web logs, see the web attack fundamentals in that guide. The official OWASP description of this category is at OWASP A02:2025 Security Misconfiguration.

Table of Contents

1. What Is Security Misconfiguration?
2. How Security Misconfiguration Is Exploited
3. Security Misconfiguration Attack Examples
4. Security Misconfiguration Indicators and Evidence
5. How to Detect Security Misconfiguration with Wazuh
6. Practical SOC Investigation Scenario: Exposed .env File on a Retail Storefront
7. Incident Response Process
8. Prevention and Remediation
9. Related OWASP Categories
10. Frequently Asked Questions
11. Conclusion
12. Continue the OWASP Top 10 Series
13. References and Further Reading

What Is Security Misconfiguration?

Definition: Security Misconfiguration means a system, application or cloud service is set up insecurely, for example default passwords left enabled, debug pages exposed, directory listing turned on, detailed error messages shown to users, or cloud storage open to the internet.

Key terms:

1. Hardening means removing unnecessary features and setting secure values.
2. Default credentials are usernames and passwords that ship with a product, such as admin and admin.
3. Directory listing means the web server shows a list of files in a folder when no index page exists.
4. Stack trace is a detailed error report showing code files, functions and sometimes versions. It helps developers and also attackers.
5. Security headers are HTTP response headers such as Strict-Transport-Security and Content-Security-Policy that tell browsers to apply protections.
6. XXE (XML External Entity, CWE-611) is when an XML parser is configured to process external entities, letting an attacker read local files or reach internal systems. OWASP lists it as a notable CWE in A02.
7. Configuration drift means a server slowly moves away from its approved secure baseline.

What weakness it represents: Missing or wrong security settings anywhere in the stack: operating system, web server, application server, framework, database, container or cloud service. OWASP lists CWE-16 Configuration as a notable CWE.

Why it happens:

1. Products ship with convenient but insecure defaults.
2. Test settings (debug mode, sample apps) are copied to production.
3. There is no repeatable hardening process, so each server is different.
4. Teams prioritize backward compatibility over security.
5. Cloud permissions are complex and easy to get wrong.

Why attackers target it: It needs little skill. Internet scanners constantly look for /.git/, /.env, /phpinfo.php, admin consoles and open storage buckets. OWASP reports that 100% of tested applications had some form of misconfiguration, and the category moved from number 5 to number 2.

What can happen after successful exploitation: Leaked secrets and source code, admin takeover through default passwords, server takeover through exposed management consoles, cloud data exposure, and better information for later attacks.

Business assets affected: source code, API keys and database passwords in config files, customer data in cloud storage, admin consoles, and the servers themselves.

How Security Misconfiguration Is Exploited

1. What the attacker needs first: Only internet access and a scanner or a list of common paths. No account is needed.
2. What is targeted: Known file paths, default admin pages, management ports, error pages, cloud storage URLs and XML upload features.
3. What the attacker sends: Many GET requests to common sensitive paths, login attempts with default passwords, malformed input to trigger verbose errors, or XML containing an external entity.
4. What the vulnerable application does: Returns the file, shows the listing, accepts the default password, shows the stack trace, or processes the external entity.
5. How the attacker exploits it: Uses the leaked secret or source code to go deeper, logs in to the admin console, or downloads exposed data.
6. What happens on success: Secrets exposed, admin access gained, data downloaded.
7. Evidence left behind: Bursts of 404 responses from scanning, a few 200 responses on sensitive paths with meaningful sizes, logins to admin consoles, SCA check failures, unexpected config file changes.

Security Misconfiguration Attack Examples

Example 1: Exposed .env file on a production web server

1. Situation: A retail company deploys a PHP or Node.js site by copying the project folder. The .env file, which holds the database password and a payment API key, ends up inside the public web root.
2. Attacker objective: Steal secrets.
3. Attacker actions: Runs an internet scanner that requests common files.
4. Representative access log entries:

192.0.2.88 - - [05/Nov/2026:03:11:02 +0000] "GET /.git/config HTTP/1.1" 404 153 "-" "Mozilla/5.0 zgrab/0.x"
192.0.2.88 - - [05/Nov/2026:03:11:02 +0000] "GET /phpinfo.php HTTP/1.1" 404 153 "-" "Mozilla/5.0 zgrab/0.x"
192.0.2.88 - - [05/Nov/2026:03:11:03 +0000] "GET /.env HTTP/1.1" 200 1312 "-" "Mozilla/5.0 zgrab/0.x"

5. Vulnerable behavior: The server serves .env as a plain text file.
6. Attempt versus success: The 404 lines are attempts. The 200 with 1,312 bytes on /.env strongly suggests the file was downloaded. Confirm by checking whether that file exists in the web root and what it contains.
7. Impact: Database and payment API credentials exposed. Treat them as compromised and rotate them.

Example 2: Default password on an application server admin console

1. Situation: A logistics company runs a Java application server. Its management console is reachable on the internet at /manager/html, and the default account was never changed.
2. Attacker objective: Deploy their own application (a web shell) to run commands.
3. Attacker actions: Tries common default credentials against the console.
4. Representative evidence:

198.51.100.9 - admin [05/Nov/2026:04:20:11 +0000] "GET /manager/html HTTP/1.1" 401 2473 "-" "curl/8.5.0"
198.51.100.9 - admin [05/Nov/2026:04:20:14 +0000] "GET /manager/html HTTP/1.1" 200 15420 "-" "curl/8.5.0"
198.51.100.9 - admin [05/Nov/2026:04:21:02 +0000] "POST /manager/html/upload HTTP/1.1" 200 16110 "-" "curl/8.5.0"

5. Vulnerable behavior: The console accepts the default password and allows uploads.
6. Attempt versus success: The 401 is a failed attempt. The 200 on /manager/html with the username field filled shows a successful login. The POST to /upload shows a deployment action, which must be confirmed with file integrity data on the server.
7. Impact: Full server compromise.

Example 3: Verbose error message

A request with an unexpected character returns a full stack trace showing the framework name and version. This is reconnaissance for the attacker. It is a misconfiguration when production is configured to show detailed errors. (Compare with A10 in the category comparison section: A10 is about the code not handling the abnormal condition safely.)

Security Misconfiguration Indicators and Evidence

• Many 404 responses for common sensitive files from one IP
  • Where you see it: Access logs
  • Strength: Suspicious, usually internet scanning
• 200 response on /.env, /.git/, backup files, phpinfo.php, /actuator/env
  • Where you see it: Access logs
  • Strength: Strong evidence of exposure
• Successful login to an admin console with a default username such as admin
  • Where you see it: App server or access logs with user field
  • Strength: Strong
• Responses with stack traces or framework versions
  • Where you see it: App logs, WAF, or manual check of the response
  • Strength: Strong evidence of misconfiguration, not of exploitation
• Unexpected change to web server config files
  • Where you see it: Wazuh FIM
  • Strength: Strong sign of drift or tampering, needs change ticket check
• SCA check changes from passed to failed
  • Where you see it: Wazuh SCA
  • Strength: Strong evidence of a weak setting
• Cloud storage object read by unknown identities
  • Where you see it: Cloud audit logs
  • Strength: Strong if the bucket should be private
• XML requests with <!DOCTYPE and <!ENTITY
  • Where you see it: WAF or app logs
  • Strength: Suspicious (XXE attempt)
• New process started by the app server user after an admin upload
  • Where you see it: Sysmon, auditd
  • Strength: Strong sign of exploitation

How to Detect Security Misconfiguration with Wazuh

Required Log Sources

• Web server access logs
  • Necessary or optional: Necessary
  • Why: Shows requests for sensitive paths and their status codes
• Wazuh SCA (Security Configuration Assessment) results
  • Necessary or optional: Necessary for configuration visibility
  • Why: Checks hosts against hardening policies such as CIS benchmarks
• Wazuh FIM (File Integrity Monitoring) on config folders
  • Necessary or optional: Necessary
  • Why: Detects config changes
• Web server error logs
  • Necessary or optional: Recommended
  • Why: Shows forbidden access, invalid requests, stack traces
• Application server logs (admin console logins)
  • Necessary or optional: Recommended
  • Why: Shows default account use
• WAF or ModSecurity logs
  • Necessary or optional: Optional
  • Why: Shows XXE and other blocked payloads
• Cloud audit logs (for example AWS CloudTrail) through the Wazuh cloud modules
  • Necessary or optional: Optional, needed for cloud misconfiguration
  • Why: Shows bucket policy changes and public access
• Process telemetry (Sysmon, auditd)
  • Necessary or optional: Optional
  • Why: Proves code execution after console abuse

What Wazuh Can and Cannot Detect

1. Directly with built in features:
   1. SCA runs policy checks on agents. Wazuh ships web server policies including cis_apache_24, cis_nginx_1, cis_iis_10 and web_vulnerabilities (Wazuh documentation, “Available SCA policies”). Built in SCA rules include 19007 (level 7) for a failed check and 19011 (level 9) when a check changes from passed to failed.
   2. FIM built in rules 550 “Integrity checksum changed” (level 7), 553 “File deleted” (level 7) and 554 “File added to the system” (level 5).
   3. Web rules 31516 “Suspicious URL access” (level 6) matches paths such as .bak, .swp, /.htaccess, /server-status, /.ssh, /.history. Rule 31515 detects scans for phpMyAdmin/scripts/setup.php. Rule 31151 detects many 4xx errors from one IP.
   4. Apache error log rules such as 30105 “Apache: Attempt to access forbidden file or directory.” and 30106 “Apache: Attempt to access forbidden directory index.”, and ModSecurity rules 30118 and 30411.
2. Needs custom rules: 200 responses on sensitive files, admin console logins with default usernames, config changes on specific folders with higher severity.
3. Needs application or WAF logs: XXE payloads and stack traces in responses, because request and response bodies are not in access logs.
4. Needs external integrations: cloud storage and IAM misconfiguration (Wazuh AWS, Azure or GCP modules), or a dedicated cloud security posture tool.
5. Cannot be reliably detected by Wazuh alone: a misconfiguration that nobody has touched yet (for example an exposed bucket nobody has read) unless an SCA policy or cloud scan checks for it. Detection of attacker activity is not the same as finding the weak setting.
6. Suspicious versus proof: A 200 on /.env is strong suspicion. Proof is confirming the file exists in the web root and contains secrets.

Wazuh Rules for Security Misconfiguration

All rules below are custom rules (examples).

Rule logic:

1. 100201: A sensitive file or debug endpoint returned 200.
2. 100202: A request for the same sensitive paths with any other status (probing).
3. 100203: FIM reports a modified file under web server configuration folders.
4. 100204: An SCA check in a web server policy changed from passed to failed.

<group name="custom_owasp,owasp_a02,">

  <!-- Custom rule (example): sensitive file or debug endpoint served successfully -->
  <rule id="100201" level="10">
    <if_sid>31100</if_sid>
    <url type="pcre2">(?i)(/\.git/|/\.env($|\?)|/phpinfo\.php|/actuator/(env|heapdump)|/server-status|/web\.config|/backup\.(zip|sql|tar\.gz)|/\.DS_Store)</url>
    <id>^200$</id>
    <description>OWASP A02: Sensitive file or debug endpoint returned 200: $(url)</description>
    <mitre>
      <id>T1190</id>
    </mitre>
  </rule>

  <!-- Custom rule (example): probing for the same sensitive paths -->
  <rule id="100202" level="6">
    <if_sid>31100</if_sid>
    <url type="pcre2">(?i)(/\.git/|/\.env($|\?)|/phpinfo\.php|/actuator/(env|heapdump)|/server-status|/web\.config|/backup\.(zip|sql|tar\.gz)|/\.DS_Store)</url>
    <description>OWASP A02: Probe for sensitive file or debug endpoint: $(url)</description>
  </rule>

  <!-- Custom rule (example): web server configuration file modified -->
  <rule id="100203" level="10">
    <if_sid>550</if_sid>
    <field name="file" type="pcre2">^/etc/(nginx|apache2|httpd)/</field>
    <description>OWASP A02: Web server configuration file modified: $(file)</description>
    <mitre>
      <id>T1562</id>
    </mitre>
  </rule>

  <!-- Custom rule (example): web server hardening check regressed -->
  <rule id="100204" level="10">
    <if_sid>19011</if_sid>
    <field name="sca.policy" type="pcre2">(?i)(apache|nginx|iis)</field>
    <description>OWASP A02: Web server hardening check changed from passed to failed: $(sca.check.title)</description>
  </rule>

</group>

Notes on the rules:

1. 100201 and 100202 inspect url and id from the web-accesslog decoder. Because Wazuh checks sibling rules from the highest level down, 100201 (level 10) is tested before 100202 (level 6), so a 200 produces 100201 and other codes produce 100202. The exception is /server-status: built in rule 31516 has the same level (6) and is loaded before custom rules, so non 200 requests for that path produce 31516 instead of 100202.
2. 100203 uses the FIM field file. The Wazuh FIM documentation shows custom rules with <if_sid>550</if_sid> and <field name="file">. The value appears in alerts as syscheck.path. FIM must be monitoring these folders on the agent, for example:

<!-- Agent ossec.conf, inside <syscheck> -->
<directories realtime="yes" report_changes="yes">/etc/nginx</directories>

3. 100204 uses sca.policy and sca.check.title, which the built in SCA rules themselves use in their descriptions.

Why these levels: A served secret file (100201) or a hardening regression (100204) needs action the same day, so level 10. Probes (100202) are very common internet noise, so level 6. Config changes (100203) may be legitimate maintenance, so level 10 means “verify against a change ticket”.

How to test:

1. Paste into wazuh-logtest:

192.0.2.88 - - [05/Nov/2026:03:11:03 +0000] "GET /.env HTTP/1.1" 200 1312 "-" "Mozilla/5.0 zgrab/0.x"

Expected: rule 100201, level 10.

2. Change 200 to 404 and paste again. Expected: rule 100202, level 6.
3. FIM and SCA rules cannot be tested by pasting plain text. Test them on a lab agent: change a comment in /etc/nginx/nginx.conf and wait for the FIM event, or deliberately break a hardening setting and wait for the next SCA scan.

Expected alert (representative, shortened):

{
  "rule": { "level": 10, "id": "100201", "description": "OWASP A02: Sensitive file or debug endpoint returned 200: /.env" },
  "agent": { "name": "shop-web-02" },
  "decoder": { "name": "web-accesslog" },
  "data": { "srcip": "192.0.2.88", "protocol": "GET", "url": "/.env", "id": "200" },
  "location": "/var/log/apache2/access.log"
}

Investigating the Alert in Wazuh

1. Find the alert: Threat Hunting then Events, filter rule.id:100201. For configuration findings use the Configuration Assessment module view for the agent. For file changes use the File Integrity Monitoring module.
2. Fields to inspect: data.url, data.id, data.srcip, agent.name, full_log (for bytes and user agent). For FIM: syscheck.path, syscheck.event, syscheck.diff (when report_changes is on), syscheck.md5_after. For SCA: data.sca.policy, data.sca.check.title, data.sca.check.result.
3. Source IP: Check reputation and whether the IP scanned many paths (rule.id:31151 or rule.id:100202 with the same IP).
4. Affected endpoint: agent.name and location.
5. User account: Usually none for file exposure. For console logins, the user is in the access log (third field) or app server logs.
6. Timestamps: When was the file first exposed (deployment time) and when was it first read?
7. Correlate: Look for later use of leaked secrets, such as database logins from new IPs, or API calls with the leaked key.
8. Success check: Response size compared with the real file size. Ask the system owner to confirm the file is present in the web root.
9. Impact: List every secret in the file and the systems they unlock.
10. Document: Path, time, IP, bytes, secrets involved, rotation status.

Useful Wazuh Dashboard Queries

• rule.id:100201
  • What it finds: Sensitive files served with 200
  • What to look for: Which files and which servers
• rule.id:(100202 or 31516 or 31515)
  • What it finds: Probes for sensitive paths
  • What to look for: Top source IPs, scanners versus targeted
• rule.id:31151
  • What it finds: Many 4xx errors from one IP
  • What to look for: Scanning bursts
• rule.groups:sca and rule.id:19011
  • What it finds: SCA checks that regressed
  • What to look for: Which host and setting
• rule.id:100203 or (rule.id:550 and syscheck.path:/etc/nginx*)
  • What it finds: Web config changes
  • What to look for: Matching change ticket, syscheck.diff content
• data.url:*manager/html* and data.id:200
  • What it finds: Successful access to an app server console
  • What to look for: Source IP and username in full_log

Detection Limitations

1. No scanning, no alert: A misconfiguration with no attacker activity is invisible to log rules. SCA and external scans are needed.
2. SCA coverage: SCA only checks what its policies contain. Custom application settings (for example a framework debug flag) need custom SCA policies.
3. Cloud blind spot: Cloud storage permissions are not visible without cloud log integration.
4. False positives: Health checks hitting /server-status, internal monitoring tools, and legitimate config changes.
5. Rewritten 200 responses: Some apps return 200 with a custom “not found” page. Always check the bytes.
6. Improve visibility: Enable SCA with web server policies, monitor config folders with FIM and report_changes, collect error logs, and integrate cloud audit logs.

Practical SOC Investigation Scenario: Exposed .env File on a Retail Storefront

Organization and affected application. An online retailer deploys a new storefront version every week. The site runs on Apache, and Wazuh agents collect access logs, FIM and SCA data from the web servers.

Initial suspicious activity. An external IP sends hundreds of requests for common sensitive file paths within two minutes.

Initial detection. At 03:11 UTC, custom rule 100201 fires: “Sensitive file or debug endpoint returned 200: /.env” on shop-web-02 from 192.0.2.88. Built in rule 31151 (multiple 400 errors from the same source IP) fires for the same IP.

Logs examined. The analyst reviews the access logs for the source IP, searches data.url:"/.env" across all agents for 30 days, and checks FIM events for the web root.

Suspicious indicators. About 240 requests from the IP use a scanner user agent and mostly return 404. Only /.env returns 200, with 1,312 bytes, which is consistent with a real configuration file.

Event correlation. Three other IPs also received 200 for /.env since the last deployment, five days earlier. A FIM event (syscheck.event:added) shows that the file appeared in the web root during that deployment. The system owner confirms that the file holds a database password and a payment provider API key.

Assessment of successful exploitation. The 404 probes are attack attempts. The 200 responses with the expected file size show the file was successfully downloaded by at least four external IPs. No application code was exploited; the server simply served a file that should never have been public. Database logs show no logins from unknown IPs so far, so use of the stolen credentials is not confirmed.

Potential business impact. Two production credentials have been exposed for five days. The payment key must be treated as compromised.

Incident response actions. The SOC escalates the case as High. It recommends removing the file immediately, rotating both secrets and watching for any use of the old key. System administrators remove the file and add a web server rule that denies access to dot files. The payment and database owners rotate the credentials.

Recommended remediation. DevOps fixes the deployment script so it excludes .env files, and moves secrets to a secrets manager. Verification confirms that /.env now returns 403 or 404 and that no new 100201 alerts appear. Root cause: A02 Security Misconfiguration.

Incident Response Process

• Initial triage
  • Category specific action: Confirm the path, status, bytes and server; check if it is a scanner or targeted
  • Who: SOC L1
• Evidence collection
  • Category specific action: Save alert JSON, access logs, FIM and SCA records, deployment time
  • Who: SOC L1 or L2
• Event correlation
  • Category specific action: Find every IP that received the resource; look for later use of exposed secrets
  • Who: SOC L2
• Severity assessment
  • Category specific action: Probe only (Low), exposed config without secrets (Medium), exposed secrets or console takeover (High or Critical)
  • Who: SOC L2
• Impact assessment
  • Category specific action: List secrets, data or functions exposed
  • Who: SOC with system owner
• Escalation
  • Category specific action: Incident lead, system owner, secret owners
  • Who: SOC
• Containment recommendation
  • Category specific action: Remove file, block path, disable console, rotate secrets, restrict cloud bucket
  • Who: SOC recommends; admins execute
• Coordination
  • Category specific action: DevOps fixes pipeline; admins harden configuration
  • Who: Admins, DevOps
• Remediation verification
  • Category specific action: Re run requests, re run SCA scan, confirm FIM baseline
  • Who: SOC
• Documentation and closure
  • Category specific action: Root cause, exposure window, rotated secrets, new rules
  • Who: SOC and incident lead

Prevention and Remediation

1. Use a repeatable, automated hardening process so development, test and production are configured the same way (with different credentials).
2. Remove sample apps, unused features, default accounts and test frameworks.
3. Disable directory listing and block dot files and backup files at the web server.
4. Show generic error pages in production and log details internally.
5. Send security headers.
6. Review cloud storage permissions and use short lived credentials instead of static keys in config files.
7. Run SCA and external scans continuously and alert on regressions.
8. Monitor configuration folders with FIM.

Related OWASP Categories

1. A03:2025 Software Supply Chain Failures: If updating the software fixes the problem, it is a supply chain issue; if changing a setting fixes it, it is a misconfiguration. See the side by side comparison.
2. A10:2025 Mishandling of Exceptional Conditions: Verbose error pages in production are a configuration problem, while unsafe handling of the error itself is A10. See the side by side comparison.
3. A04:2025 Cryptographic Failures: Weak TLS protocols and ciphers are configuration settings that protect data, so they are discussed under Cryptographic Failures.

Frequently Asked Questions

Is a 404 response on /.env a security incident?

No. A 404 means the probe failed, and such requests are constant internet noise. The event becomes important when the response is 200 with a size that matches real file content. Then the analyst identifies every IP that downloaded the file and treats any secrets inside as compromised.

What does Wazuh SCA check?

Security Configuration Assessment runs policy checks on agents and reports whether each check passed or failed. Wazuh ships policies based on CIS benchmarks, including web server policies such as cis_apache_24, cis_nginx_1 and cis_iis_10. SCA only checks what its policies contain, so application specific settings need custom policies.

Where does XXE fit in the OWASP Top 10 2025?

OWASP lists XML External Entity processing (CWE-611) as a notable weakness in A02, because it comes from an XML parser configured to process external entities. Detecting XXE attempts requires WAF or application logs that capture XML request bodies, because access logs do not contain bodies.

How can a SOC tell configuration drift from tampering?

The analyst compares the FIM event with change management records, checks who made the change and with which process (FIM whodata), reviews the diff, and looks for other suspicious activity on the same host at the same time. An approved change explains drift; an unexplained change with other suspicious activity suggests tampering.

What should happen after a secret is exposed?

The secret must be rotated, even if there is no evidence of misuse yet. The SOC also searches for use of the old credential, such as database logins or API calls from unknown IPs, and confirms that the file is no longer reachable.

Conclusion

Security misconfiguration is common because modern software has many settings and insecure defaults. For a SOC, it has two sides: finding weak settings before attackers do, and detecting when attackers use them. Wazuh covers both with SCA policies for hardening, FIM for configuration changes and access log rules for probes and successful downloads of sensitive files.

When an exposure is confirmed, the most important response steps are scoping who downloaded what, rotating every exposed secret and fixing the process that created the weakness, such as a deployment script or a missing hardening baseline.

Continue the OWASP Top 10 Series

1. Series overview: OWASP Top 10 for SOC Analysts: Web Attack Detection and Investigation with Wazuh
2. Previous category: Broken Access Control (OWASP A01:2025): Detection and Investigation with Wazuh
3. Next category: Software Supply Chain Failures (OWASP A03:2025): Detection and Investigation with Wazuh

References and Further Reading

1. OWASP A02:2025 Security Misconfiguration
2. CWE-16 Configuration
3. CWE-611 Improper Restriction of XML External Entity Reference
4. MITRE ATT&CK T1190 Exploit Public Facing Application
5. MITRE ATT&CK T1562 Impair Defenses
6. Wazuh documentation: Available SCA policies
7. Wazuh documentation: File integrity monitoring basic settings
8. Wazuh documentation: Creating custom FIM rules
9. Wazuh documentation: Rules syntax
10. Wazuh documentation: Custom rules
11. Wazuh documentation: Testing decoders and rules
12. Wazuh built in web rules: 0245-web_rules.xml
13. OpenSearch Dashboards Query Language (DQL)