Detection rules › Splunk

Ollama Possible API Endpoint Scan Reconnaissance

Status
experimental
Severity
low
Group by
_time, attack_type, dest, host, methods, severity, src, status_codes, total_requests
Author
Rod Soto
Source
github.com/splunk/security_content

Detects API reconnaissance and endpoint scanning activity against Ollama servers by identifying sources probing multiple API endpoints within short timeframes, particularly when using HEAD requests or accessing diverse endpoint paths, which indicates systematic enumeration to map the API surface, discover hidden endpoints, or identify vulnerabilities before launching targeted attacks.

MITRE ATT&CK coverage

TacticTechniques
ReconnaissanceT1595 Active Scanning

Rule body splunk

name: Ollama Possible API Endpoint Scan Reconnaissance
id: ad3f352a-0347-48ee-86b9-670b5025a548
version: 5
creation_date: '2025-10-13'
modification_date: '2026-05-13'
author: Rod Soto
status: experimental
type: Anomaly
description: Detects API reconnaissance and endpoint scanning activity against Ollama servers by identifying sources probing multiple API endpoints within short timeframes, particularly when using HEAD requests or accessing diverse endpoint paths, which indicates systematic enumeration to map the API surface, discover hidden endpoints, or identify vulnerabilities before launching targeted attacks.
data_source:
    - Ollama Server
search: |-
    `ollama_server` "[GIN]"
      | bin _time span=5m
      | stats count as total_requests, values(dest) as dest, values(http_method) as methods, values(status) as status_codes
        BY _time, src, host
      | where total_requests > 120
      | eval severity="medium"
      | eval attack_type="API Activity Surge"
      | stats count
        BY _time, host, src,
           total_requests, dest, methods,
           status_codes, severity, attack_type
      | `ollama_possible_api_endpoint_scan_reconnaissance_filter`
how_to_implement: 'Ingest Ollama logs via Splunk TA-ollama add-on by configuring file monitoring inputs pointed to your Ollama server log directories (sourcetype: ollama:server), or enable HTTP Event Collector (HEC) for real-time API telemetry and prompt analytics (sourcetypes: ollama:api, ollama:prompts). CIM compatibility using the Web datamodel for standardized security detections.'
known_false_positives: Legitimate web application clients or mobile apps that access multiple API endpoints as part of normal functionality, monitoring and health check systems probing various endpoints for availability, load balancers performing health checks across different paths, API testing frameworks during development and QA processes, or users navigating through web interfaces that trigger multiple API calls may generate similar patterns during normal operations.
references:
    - https://github.com/rosplk/ta-ollama
drilldown_searches:
    - name: View the detection results for - "$src$"
      search: '%original_detection_search% | search  "$src = "$src$"'
      earliest_offset: $info_min_time$
      latest_offset: $info_max_time$
    - name: View risk events for the last 7 days for - "$src$"
      search: '| from datamodel Risk.All_Risk | search normalized_risk_object IN ("$src$") | stats count min(_time) as firstTime max(_time) as lastTime values(search_name) as "Search Name" values(risk_message) as "Risk Message" values(analyticstories) as "Analytic Stories" values(annotations._all) as "Annotations" values(annotations.mitre_attack.mitre_tactic) as "ATT&CK Tactics" by normalized_risk_object | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`'
      earliest_offset: 7d
      latest_offset: "0"
intermediate_findings:
    entities:
        - field: src
          type: system
          score: 20
          message: API reconnaissance activity detected from $src$ on $host$ with $total_requests$ requests across different endpoints using methods $methods$ and receiving status codes $status_codes$, indicating systematic endpoint enumeration to map API attack surface and identify potential vulnerabilities.
analytic_story:
    - Suspicious Ollama Activities
asset_type: Web Application
mitre_attack_id:
    - T1595
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: application
security_domain: endpoint
tests:
    - name: True Positive Test
      attack_data:
        - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/ollama/server.log
          sourcetype: ollama:server
          source: server.log
      test_type: experimental
      description: This test is a legacy experimental test and may not be accurate.

Stages and Predicates

Stage 1: search

`ollama_server` "[GIN]"

Stage 2: bucket

| bin _time span=5m

Stage 3: stats

| stats count as total_requests, values(dest) as dest, values(http_method) as methods, values(status) as status_codes
    BY _time, src, host

Stage 4: where

| where total_requests > 120

Stage 5: eval

| eval severity="medium"

Stage 6: eval

| eval attack_type="API Activity Surge"

Stage 7: stats

| stats count
    BY _time, host, src,
       total_requests, dest, methods,
       status_codes, severity, attack_type

Stage 8: search

| `ollama_possible_api_endpoint_scan_reconnaissance_filter`

Indicators

Each row is a field, operator, and value that the rule matches. The corpus column counts how many other rules in the catalog look for the same combination: high numbers point to widely-used, community-vetted indicators. Blank or 1 shows that the indicator is specific to this rule.

FieldKindValues
sourcetypeeq
  • ollama:server
total_requestsgt
  • 120

Search terms

Bare-string tokens in the SPL search body. Splunk matches each token against _raw (the untyped raw event text) anywhere it appears, not against a specific field. These don't surface in the Indicators table because they aren't predicates on a known field.

StageTerm
1"[GIN]"