Detection rules › Panther
MongoDB org membership restriction disabled
You can configure Atlas to require API access lists at the organization level. When you enable IP access list for the Atlas Administration API, all API calls in that organization must originate from a valid entry in the associated Atlas Administration API key access list. This rule detects when IP access list is disabled
MITRE ATT&CK coverage
| Tactic | Techniques |
|---|---|
| Persistence | T1556.009 Modify Authentication Process: Conditional Access Policies |
Rule body yaml
AnalysisType: rule
Description:
You can configure Atlas to require API access lists at the organization level.
When you enable IP access list for the Atlas Administration API, all API calls in that organization must originate
from a valid entry in the associated Atlas Administration API key access list.
This rule detects when IP access list is disabled
DisplayName: "MongoDB org membership restriction disabled"
Enabled: true
LogTypes:
- MongoDB.OrganizationEvent
RuleID: "MongoDB.org.Membership.Restriction.Disabled"
Filename: mongodb_org_membership_restriction_disabled.py
Severity: High
Tags:
- MongoDB
- Persistence
- Modify Authentication Process
- Conditional Access Policies
Reports:
MITRE ATT&CK:
- TA0003:T1556.009 # Modify Authentication Process
Reference: https://www.mongodb.com/docs/atlas/tutorial/manage-organizations/
Runbook: Check if this activity is legitimate. If not, re-enable IP access list for the Atlas Administration API
Tests:
- Name: Restriction disabled
ExpectedResult: true
Log:
{
"created": "2024-04-03 15:03:51.000000000",
"currentValue": {},
"eventTypeName": "ORG_PUBLIC_API_ACCESS_LIST_NOT_REQUIRED",
"id": "alert_id",
"isGlobalAdmin": false,
"orgId": "some_org_id",
"remoteAddress": "1.2.3.4",
"userId": "user_id",
"username": "some_user@company.com",
}
- Name: Restriction enabled
ExpectedResult: false
Log:
{
"created": "2024-04-03 15:03:51.000000000",
"currentValue": {},
"eventTypeName": "ORG_PUBLIC_API_ACCESS_LIST_REQUIRED",
"id": "alert_id",
"isGlobalAdmin": false,
"orgId": "some_org_id",
"remoteAddress": "1.2.3.4",
"userId": "user_id",
"username": "some_user@company.com",
}
- Name: Other activity
ExpectedResult: false
Log:
{
"alertConfigId": "alert_id",
"created": "2024-04-01 11:58:52.000000000",
"currentValue": {},
"eventTypeName": "ALERT_CONFIG_DELETED_AUDIT",
"id": "alert_id",
"isGlobalAdmin": false,
"links": [],
"orgId": "some_org_id",
"remoteAddress": "1.2.3.4",
"userId": "user_id",
"username": "some_user@company.com",
}
DedupPeriodMinutes: 60
Threshold: 1
Detection logic
Condition
eventTypeName eq "ORG_PUBLIC_API_ACCESS_LIST_NOT_REQUIRED"
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 |
|
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 |