Detection rules › Panther
MongoDB access allowed from anywhere
Atlas only allows client connections to the database deployment from entries in the project's IP access list. This rule detects when 0.0.0.0/0 is added to that list, which allows access from anywhere.
MITRE ATT&CK coverage
| Tactic | Techniques |
|---|---|
| Persistence | T1556.009 Modify Authentication Process: Conditional Access Policies |
| Lateral Movement | T1021.007 Remote Services: Cloud Services |
Rule body yaml
AnalysisType: rule
Description: Atlas only allows client connections to the database deployment from entries in the project's IP access list. This rule detects when 0.0.0.0/0 is added to that list, which allows access from anywhere.
DisplayName: "MongoDB access allowed from anywhere"
Enabled: true
LogTypes:
- MongoDB.ProjectEvent
RuleID: "MongoDB.Access.Allowed.From.Anywhere"
Filename: mongodb_access_allowed_from_anywhere.py
Severity: High
Tags:
- MongoDB
- Persistence
- Remote Services
- Modify Authentication Process - Conditional Access Policies
Reports:
MITRE ATT&CK:
- TA0003:T1556.009 # Modify Authentication Process - Conditional Access Policies
- TA0008:T1021.007 # Remote Services
Reference: https://www.mongodb.com/docs/atlas/security/ip-access-list/
Runbook: Check if this activity was legitimate. If not, delete 0.0.0.0/0 from the list of allowed ips.
Tests:
- Name: Allowed access from anywhere
ExpectedResult: true
Log:
{
"created": "2024-04-03 11:13:04.000000000",
"currentValue": {},
"eventTypeName": "NETWORK_PERMISSION_ENTRY_ADDED",
"groupId": "some_group_id",
"id": "123abc",
"isGlobalAdmin": false,
"remoteAddress": "1.2.3.4",
"userId": "123abc",
"username": "some_user@company.com",
"whitelistEntry": "0.0.0.0/0",
}
- Name: Allowed access from specific ip
ExpectedResult: false
Log:
{
"created": "2024-04-03 11:13:04.000000000",
"currentValue": {},
"eventTypeName": "NETWORK_PERMISSION_ENTRY_ADDED",
"groupId": "some_group_id",
"id": "123abc",
"isGlobalAdmin": false,
"remoteAddress": "1.2.3.4",
"userId": "123abc",
"username": "some_user@company.com",
"whitelistEntry": "1.2.3.4/32",
}
DedupPeriodMinutes: 60
Threshold: 1
Detection logic
Condition
eventTypeName eq "NETWORK_PERMISSION_ENTRY_ADDED"
whitelistEntry eq "0.0.0.0/0"
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.
| Field | Kind | Values |
|---|---|---|
eventTypeName | eq |
|
whitelistEntry | eq |
|
Output fields
Fields the rule emits when it matches. Chronicle authors list these in the outcome block; they appear on the detection and $risk_score drives alerting. Sentinel / Defender XDR rules build them up through project / summarize / extend stages. Sentinel maps these into alert fields via entityMappings and customDetails; Defender XDR custom detections surface them as alert fields directly.
| Field | Source |
|---|---|
username | |
target_username | targetUsername |
org_id | orgId |
remote_address | remoteAddress |
groupId |