User Added as Owner for Azure Service Principal

Rule ID

PH_Rule_ES_IMPORT_AZURE_21

Default Status

Enabled

Description

Identifies when a user is added as an owner for an Azure service principal. The service principal object defines what the application can do in the specific tenant, who can access the application, and what resources the app can access. A service principal object is created when an application is given permission to access resources in a tenant. An adversary may add a user account as an owner for a service principal and use that account in order to define what an application can do in the Azure AD tenant.

Severity

MITRE ATT&CK® Tactics

Initial Access

Initial Access consists of techniques that use various entry vectors to gain their initial foothold within a network. Techniques used to gain a foothold include targeted spearphishing and exploiting weaknesses on public-facing web servers. Footholds gained through initial access may allow for continued access, like valid accounts and use of external remote services, or may be limited-use due to changing passwords.

https://attack.mitre.org/tactics/TA0001

MITRE ATT&CK® Techniques

T1078.004

Valid Accounts: Cloud Accounts

Adversaries may obtain and abuse credentials of a cloud account as a means of gaining Initial Access, Persistence, Privilege Escalation, or Defense Evasion. Cloud accounts are those created and configured by an organization for use by users, remote support, services, or for administration of resources within a cloud service provider or SaaS application. In some cases, cloud accounts may be federated with traditional identity management system, such as Window Active Directory. Compromised credentials for cloud accounts can be used to harvest sensitive data from online storage accounts and databases.

https://attack.mitre.org/techniques/T1078/004

Impacts

Server

Data Source

MS Azure via Azure Event Hub (AZURE_PYTHON_SDK)

Detection

Correlation

Remediation Guidance

No remediation guidance specified

Time Window

If the following pattern or patterns match an ingested event within the given time window in seconds, trigger an incident.

300 seconds

Trigger Conditions

If the following defined pattern/s occur within a 300 second time window.

Filter

SubPattern Definitions

SubPattern Name: Filter

This is the named definition of the event query, this is important if multiple subpatterns are defined to distinguish them.

SubPattern Query

This is the query logic that matches incoming events

eventType = "MS_EvtHub_add_owner_to_service_principal"

Group by Attributes

This defines how matching events are aggregated, only events with the same matching attribute values are grouped into one unique incident ID

user

Aggregate Constraint

This is most typically a numerical constraint that defines when the rule should trigger an incident

COUNT(*) >= 1

Incident Attribute Mapping

This section defines which fields in matching raw events should be mapped to the incident attributes in the resulting incident.

The available raw event attributes to map are limited to the group by attributes and the aggregate event constraint fields for each subpattern

 user = Filter.user

FortiSIEM Rules