Detection rules › Panther

Netskope Many Unauthorized API Calls

Severity
high
Log types
Netskope.Audit
Tags
Netskope, Configuration Required, Brute Force
Reference
https://docs.netskope.com/en/netskope-help/data-security/netskope-private-access/private-access-rest-apis/
Source
github.com/panther-labs/panther-analysis

Many unauthorized API calls were observed for a user in a short period of time.

MITRE ATT&CK coverage

TacticTechniques
Credential AccessT1110 Brute Force

Rule body yaml

AnalysisType: rule
RuleID: "Netskope.UnauthorizedAPICalls"
DisplayName: "Netskope Many Unauthorized API Calls"
Enabled: true
Filename: netskope_unauthorized_api_calls.py
LogTypes:
  - Netskope.Audit
Tags:
  - Netskope
  - Configuration Required # configure threshold for your environment
  - Brute Force
Reports:
  MITRE ATT&CK:
    - TA0006:T1110
Severity: High
Description: Many unauthorized API calls were observed for a user in a short period of time.
DedupPeriodMinutes: 60
Threshold: 10
Runbook: An account is making many unauthorized API calls.  This could indicate brute force activity, or expired service account credentials.
Reference: https://docs.netskope.com/en/netskope-help/data-security/netskope-private-access/private-access-rest-apis/
Tests:
  - Name: True positive
    ExpectedResult: true
    Log:
      {
        "_id": "1e589befa3da30132362f32a",
        "_insertion_epoch_timestamp": 1702318213,
        "audit_log_event": "Rest API V2 Call",
        "count": 1,
        "is_netskope_personnel": false,
        "organization_unit": "",
        "severity_level": 2,
        "supporting_data":
          {
            "data_type": "incidents",
            "data_values":
              [
                403,
                "POST",
                "/api/v2/incidents/uba/getuci",
                "trid=ccb898fgrhvdd0v0lebg",
              ],
          },
        "timestamp": "2023-12-11 18:10:13.000000000",
        "type": "admin_audit_logs",
        "ur_normalized": "service-account",
        "user": "service-account",
      }
  - Name: True negative
    ExpectedResult: false
    Log:
      {
        "_id": "1e589befa3da30132362f32a",
        "_insertion_epoch_timestamp": 1702318213,
        "audit_log_event": "Rest API V2 Call",
        "count": 1,
        "is_netskope_personnel": false,
        "organization_unit": "",
        "severity_level": 2,
        "supporting_data":
          {
            "data_type": "incidents",
            "data_values":
              [
                200,
                "POST",
                "/api/v2/incidents/uba/getuci",
                "trid=ccb898fgrhvdd0v0lebg",
              ],
          },
        "timestamp": "2023-12-11 18:10:13.000000000",
        "type": "admin_audit_logs",
        "ur_normalized": "service-account",
        "user": "service-account",
      }

Detection logic

Condition

supporting_data.data_values is_not_null

This rule also runs imperative logic the parser cannot express as a filter; the conditions above are the structured part it could extract.

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
supporting_data.data_valuesis_not_null
  • (no value, null check)

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
user