Ollama API Accessed from External Network
Detects when the Ollama LLM server accepts connections from external IP addresses. Ollama lacks built-in authentication, so exposed instances allow unauthenticated model theft, prompt injection, and resource hijacking.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2026/01/09"
3integration = ["endpoint"]
4maturity = "production"
5updated_date = "2026/01/09"
6
7[rule]
8author = ["Elastic"]
9description = """
10Detects when the Ollama LLM server accepts connections from external IP addresses. Ollama lacks built-in authentication,
11so exposed instances allow unauthenticated model theft, prompt injection, and resource hijacking.
12"""
13from = "now-9m"
14index = ["logs-endpoint.events.network-*"]
15language = "eql"
16license = "Elastic License v2"
17name = "Ollama API Accessed from External Network"
18note = """## Triage and analysis
19
20### Investigating Ollama API Accessed from External Network
21
22This rule detects when Ollama accepts connections from external IP addresses. Ollama binds to localhost:11434 by default but can be exposed via OLLAMA_HOST. Since Ollama lacks authentication, exposed instances allow unauthenticated model theft, prompt injection, and resource hijacking.
23
24### Possible investigation steps
25
26- Check the OLLAMA_HOST environment variable to determine if external exposure was intentional.
27- Review the source IP address to identify if it's a known attacker, scanner, or miscategorized internal system.
28- Examine Ollama logs for suspicious API calls to /api/pull, /api/push, or /api/generate.
29- Check ~/.ollama/models/ for unexpected model downloads that may indicate model poisoning.
30- Review network traffic for data exfiltration following the connection.
31- Look for child processes spawned by Ollama that may indicate exploitation.
32
33### False positive analysis
34
35- Internal networks not properly classified in CIDR ranges may trigger false positives.
36- Load balancers or reverse proxies accessing Ollama from external-facing IPs within trusted infrastructure.
37- Legitimate remote access through VPN or authenticated proxy (add proxy IPs to exclusions).
38
39### Response and remediation
40
41- Restrict access immediately by setting OLLAMA_HOST=127.0.0.1:11434 or applying firewall rules.
42- If exploitation is suspected, stop Ollama and audit ~/.ollama/models/ for unauthorized models.
43- Review Ollama and system logs for signs of compromise.
44- Consider running Ollama in a container with network isolation.
45"""
46references = [
47 "https://www.greynoise.io/blog/threat-actors-actively-targeting-llms",
48 "https://atlas.mitre.org/techniques/AML.T0040",
49 "https://atlas.mitre.org/techniques/AML.T0044",
50]
51risk_score = 47
52rule_id = "d8f2a1b3-c4e5-6789-abcd-ef0123456789"
53severity = "medium"
54tags = [
55 "Domain: Endpoint",
56 "OS: Linux",
57 "OS: macOS",
58 "OS: Windows",
59 "Use Case: Threat Detection",
60 "Tactic: Initial Access",
61 "Data Source: Elastic Defend",
62 "Resources: Investigation Guide",
63 "Domain: LLM",
64 "Mitre Atlas: T0040",
65 "Mitre Atlas: T0044",
66]
67timestamp_override = "event.ingested"
68type = "eql"
69
70query = '''
71network where event.action == "connection_accepted" and
72 process.name in ("ollama", "ollama.exe") and
73 destination.port == 11434 and
74 source.ip != null and source.ip != "0.0.0.0" and
75 not cidrmatch(source.ip,
76 "10.0.0.0/8",
77 "127.0.0.0/8",
78 "169.254.0.0/16",
79 "172.16.0.0/12",
80 "192.168.0.0/16",
81 "100.64.0.0/10",
82 "::1",
83 "fe80::/10",
84 "fc00::/7",
85 "ff00::/8"
86 )
87'''
88
89
90[[rule.threat]]
91framework = "MITRE ATT&CK"
92[[rule.threat.technique]]
93id = "T1190"
94name = "Exploit Public-Facing Application"
95reference = "https://attack.mitre.org/techniques/T1190/"
96
97
98[rule.threat.tactic]
99id = "TA0001"
100name = "Initial Access"
101reference = "https://attack.mitre.org/tactics/TA0001/"
Triage and analysis
Investigating Ollama API Accessed from External Network
This rule detects when Ollama accepts connections from external IP addresses. Ollama binds to localhost:11434 by default but can be exposed via OLLAMA_HOST. Since Ollama lacks authentication, exposed instances allow unauthenticated model theft, prompt injection, and resource hijacking.
Possible investigation steps
- Check the OLLAMA_HOST environment variable to determine if external exposure was intentional.
- Review the source IP address to identify if it's a known attacker, scanner, or miscategorized internal system.
- Examine Ollama logs for suspicious API calls to /api/pull, /api/push, or /api/generate.
- Check ~/.ollama/models/ for unexpected model downloads that may indicate model poisoning.
- Review network traffic for data exfiltration following the connection.
- Look for child processes spawned by Ollama that may indicate exploitation.
False positive analysis
- Internal networks not properly classified in CIDR ranges may trigger false positives.
- Load balancers or reverse proxies accessing Ollama from external-facing IPs within trusted infrastructure.
- Legitimate remote access through VPN or authenticated proxy (add proxy IPs to exclusions).
Response and remediation
- Restrict access immediately by setting OLLAMA_HOST=127.0.0.1:11434 or applying firewall rules.
- If exploitation is suspected, stop Ollama and audit ~/.ollama/models/ for unauthorized models.
- Review Ollama and system logs for signs of compromise.
- Consider running Ollama in a container with network isolation.
References
Related rules
- GenAI Process Accessing Sensitive Files
- Suspicious React Server Child Process
- Initial Access via File Upload Followed by GET Request
- GenAI Process Compiling or Generating Executables
- GenAI Process Performing Encoding/Chunking Prior to Network Activity