During our recent incident response engagements across several Tier-2 Indian ISPs and manufacturing units, we identified a recurring pattern of unauthorized access attempts targeting the FortiOS management interface. The vulnerability, tracked as CVE-2024-55591, is an authentication bypass that allows a remote unauthenticated attacker to gain super-admin privileges. We observed that attackers are specifically targeting the /remote/logincheck URI to manipulate the authentication logic within the httpsd daemon.

Introduction to SIEM Detection Rules

SIEM detection rules serve as the programmatic logic that translates raw log data into actionable security alerts. In the context of CVE-2024-55591, these rules must distinguish between legitimate administrative logins and the anomalous request structures used by exploit payloads. We have found that relying solely on signature-based detection is insufficient, as attackers frequently vary their HTTP headers to evade basic pattern matching, often employing techniques seen in HTTP Desync and TRACE-based Attacks.

What are SIEM Detection Rules?

Detection rules are conditional statements executed against indexed log data. They leverage boolean logic, threshold counters, and behavioral modeling to identify deviations from established baselines. For Fortinet devices, we focus on logs generated by the httpsd and syslog processes, specifically looking for successful status codes (200 OK) that lack corresponding user or ui field population in the audit trail.

The Importance of Proactive Threat Detection

Waiting for a vendor patch is not a viable strategy during active exploitation cycles. We use proactive detection rules to identify "pre-exploit" activity, such as automated scanning for the /remote/logincheck endpoint. In many Indian enterprise environments, management interfaces are inadvertently exposed to the internet to facilitate remote support by third-party Managed Service Providers (MSPs). This exposure makes proactive detection the primary line of defense.

How Detection Rules Power Modern SOC Operations

Modern Security Operations Centers (SOCs) utilize these rules to automate the initial stages of the Incident Response (IR) lifecycle. By mapping rules to the MITRE ATT&CK framework, specifically T1190 (Exploit Public-Facing Application), we provide analysts with immediate context regarding the attacker's intent. When a rule triggers, it should ideally pull telemetry from the affected FortiGate appliance to confirm if a new administrative user was created.

Checking for existing administrative users on FortiOS

show full-configuration system admin user

---

Core Components and SIEM Rules Examples

Effective detection logic for Fortinet zero-days requires a multi-layered approach. We categorize these into atomic, stateful, and correlation rules. Atomic rules look for a single event, such as a specific URI access, while correlation rules look for a sequence of events, such as a login followed by a configuration change.

Common Types of Detection Logic

• Signature-based: Matches specific strings in the HTTP User-Agent or URI.
• Anomaly-based: Detects logins from unusual geographic locations or at odd hours, particularly relevant given the DPDP Act 2023 requirements for monitoring access to sensitive data.
• Behavioral: Identifies the creation of a "super-admin" account immediately following an unauthenticated request to the management port.

SIEM Rules Examples: Brute Force, Lateral Movement, and Exfiltration

While CVE-2024-55591 is an auth bypass, it is often a precursor to lateral movement. We monitor for the following patterns post-exploitation:

• Brute Force: Multiple 403 Forbidden responses followed by a 200 OK from the same source IP.
• Lateral Movement: secure SSH access for teams or RDP traffic originating from the FortiGate's internal interface toward core switches.
• Exfiltration: Large data transfers over port 443 to non-standard cloud storage providers.

Understanding Correlation vs. Simple Threshold Rules

A threshold rule might alert after 10 failed login attempts. However, a correlation rule is more effective for CVE-2024-55591. We look for a successful HTTP 200 on the management interface where the srcip has no previous history of successful authentication. This reduces the noise generated by legitimate admin activity.

Monitoring active sessions for suspicious management connections

diagnose sys session list | grep ':443 '

---

Deep Dive: Elastic SIEM Detection Rules

Elastic Security uses Event Query Language (EQL) and Lucene to parse through Fortinet logs. We have found that the Elastic Common Schema (ECS) mapping is critical for ensuring that fields like url.path and user.name are consistently populated across different FortiOS versions.

Overview of Elasticsearch SIEM Detection Rules

In Elasticsearch, we implement rules that monitor the fortinet.fortigate.log data stream. The focus is on identifying requests where the action is logged as passthrough or tunnel but occurs on the management port. We observed that during the exploitation of CVE-2024-55591, the httpsd process may log an empty string for the user field even when the response is a 200.

Managing Detection Rules in SIEM Kibana Dashboards

We utilize Kibana to visualize the frequency of hits on the /remote/logincheck endpoint. By creating a data table that aggregates source.ip against http.response.status_code, we can quickly spot scanning clusters. This is particularly useful for identifying automated botnets that are currently scanning Indian IP ranges for vulnerable FortiGate instances.

Utilizing the Elastic SIEM Detection Rules GitHub Repository

The official Elastic detection rules repository provides a baseline, but custom logic is required for zero-days. We modify the standard "Fortinet Suspicious Login" rule to include specific URI checks.

Custom EQL for CVE-2024-55591 detection

sequence by host.name   [network where event.dataset == "fortinet.fortigate" and     process.name == "httpsd" and url.path == "/remote/logincheck"]   [iam where event.action == "user-login" and user.name == "admin"]

Automating Rule Updates in Elastic Stack

We use the Detection Engine API to push updates to multiple clusters simultaneously. This is essential when a new PoC (Proof of Concept) is released and the detection logic needs to be refined within minutes across an entire MSP fleet.

---

Cloud-Native Security: Datadog SIEM Detection Rules

Datadog's Cloud SIEM is effective for distributed SD-WAN deployments common in Indian retail and logistics sectors. Its ability to correlate FortiGate logs with cloud infrastructure logs provides a holistic view of the attack surface.

Introduction to Datadog Cloud SIEM Detection Rules

Datadog uses "Security Signals" to alert on threats. We configure these signals to trigger when a FortiGate log contains a specific combination of attributes. The primary advantage here is the integration with "Threat Intel" feeds that automatically tag known malicious IPs targeting Indian infrastructure.

Configuring Real-time Threat Detection in Datadog

We implement a log-based detection rule with the following query logic:

• Query: source:fortinet @http.url_details.path:"/remote/logincheck" @http.status_code:200
• Aggregation: Count events by @network.client.ip
• Threshold: > 1 in 5 minutes

Comparing Datadog Out-of-the-Box Rules vs. Custom Logic

Out-of-the-box rules often focus on broad categories like "Geographic Improbability." While useful, they fail to catch the specific nuances of CVE-2024-55591. Our custom logic adds a filter to exclude known MSP IP ranges, which are often located in major Indian hubs like Bangalore or Pune, to reduce false positives.

---

Enterprise Standards: Splunk SIEM Detection Rules

Splunk Enterprise Security (ES) remains the standard for large-scale log aggregation in the Indian BFSI (Banking, Financial Services, and Insurance) sector. Compliance with the DPDP Act 2023 necessitates the rigorous logging and alerting capabilities that Splunk provides.

Building Correlation Searches in Splunk Enterprise Security

We use the Search Processing Language (SPL) to create correlation searches that run every 5 minutes. The goal is to identify successful logins to the management interface that do not originate from the internal management VLAN.

SPL to detect anomalous FortiGate management access

index=netfw sourcetype="fortigate_log"  url="/remote/logincheck" status=200 | stats count by src_ip, device_id | where count > 0 | lookup local_management_subnets.csv ip as src_ip OUTPUT is_internal | search is_internal="false"

Splunk Content Updates and Security Research

Splunk's "ES Content Update" (ESCU) often lags behind zero-day disclosures. We manually create "Notable Events" by analyzing the gui_login.log file on the FortiGate itself and mapping those patterns to Splunk fields.

Optimizing Splunk Rules for Performance and Accuracy

To prevent performance degradation on large Splunk indexers, we use tstats instead of raw searches where possible. This allows us to query accelerated data models, providing near real-time detection without the overhead of parsing raw strings for every search.

Optimized tstats search for faster detection

| tstats count from datamodel=Network_Traffic    where nodename=All_Traffic.Web url="/remote/logincheck"    by All_Traffic.src, All_Traffic.dest

---

Leveraging Open Source and GitHub for SIEM Logic

The security community often responds faster than commercial vendors. We monitor several GitHub repositories for Sigma rules that can be converted into platform-specific queries.

Top SIEM Detection Rules GitHub Repositories to Follow

• SigmaHQ/sigma: The primary source for generic detection logic.
• Neo23x0/signature-base: Excellent for YARA and IOC-based detection.
• Elastic/detection-rules: Direct access to Elastic's production rules.

Using Sigma Rules for Cross-Platform Detection

Sigma allows us to write a rule once and deploy it to Splunk, Elastic, and Datadog. For CVE-2024-55591, a Sigma rule would target the syslog category and look for the specific URI and status code combination. This is vital for Indian organizations running heterogeneous environments with multiple SIEM tools.

Contributing to the Global Threat Detection Community

We contribute back by sharing anonymized log samples and refined regex patterns. During the CVE-2024-23113 (Format String) outbreak, community-shared Sigma rules were the first line of defense for many organizations before official patches were available.

---

Best Practices for Implementing and Tuning SIEM Rules

Deploying a rule is only the beginning. Without proper tuning, a SOC will be overwhelmed by false positives, leading to alert fatigue and missed incidents.

Reducing False Positives through Rule Tuning

We observed that certain automated monitoring tools used by Indian ISPs perform "heartbeat" checks on the /remote/logincheck endpoint. To tune these out, we maintain a whitelist of internal monitoring IP addresses. We also filter out 404 errors, as these represent unsuccessful scanning attempts rather than successful exploitation.

Mapping Detection Rules to the MITRE ATT&CK Framework

Every rule we deploy is tagged with its relevant MITRE technique. For Fortinet exploits, we focus on:

• T1190: Exploit Public-Facing Application
• T1078.004: Valid Accounts: Cloud Accounts (if managing via FortiManager Cloud)
• T1556: Modify Authentication Process

Continuous Testing and Validation of Detection Logic

We use "Atomic Red Team" tests to validate our rules. By simulating an unauthenticated request to the management interface, we ensure the SIEM triggers the expected alert. This validation should be performed after every FortiOS firmware update, as log formats can change.

Simulating a check for the vulnerable endpoint

curl -k -I https://[FortiGate_IP]/remote/logincheck

Technical Research Findings

Our analysis of the httpsd process during exploitation reveals that the vulnerability lies in how the Node.js management layer communicates with the underlying C based authentication modules. When certain headers are omitted, the system defaults to a "trusted" state.

Log Analysis on the Appliance

To confirm exploitation locally, we examine the gui_login.log. A successful exploit often leaves a trail where the user field is empty or contains non-printable characters.

Checking local logs for suspicious login activity

fnsysctl ls -l /var/log/gui_login.log diagnose debug application httpsd -1

Vulnerability Context: CVE-2024-55591 vs. CVE-2024-23113

While CVE-2024-55591 focuses on the management interface, CVE-2024-23113 targets the fgfm (FortiGate Federation Management) daemon on port 541. We have seen attackers use the auth bypass to gain access and then leverage format string vulnerabilities to achieve persistent remote code execution (RCE) at the system level.

Feature	CVE-2024-55591	CVE-2024-23113
Target Process	httpsd (Management)	fgfmd (FGFM)
Attack Vector	Authentication Bypass	Format String Vulnerability
Port	443 / 10443	541
Impact	Super-Admin Access	Remote Code Execution

Compliance and the DPDP Act 2023

For Indian entities, a breach of a FortiGate appliance managing PII (Personally Identifiable Information) triggers mandatory reporting requirements under the Digital Personal Data Protection (DPDP) Act 2023. Effective SIEM detection rules provide the "demonstrable compliance" required by the Data Protection Board of India, showing that the entity took reasonable steps to monitor and secure data processing environments.

Verification of system version and build for vulnerability assessment

get system status | grep -E 'Version|Build'

Next Command: Execute diagnose debug application httpsd -1 on a test instance while performing a scripted login attempt to capture the exact header sequence required for high-fidelity detection logic.