AWS SAML Access by Provider User and Principal

Try in Splunk Security Cloud

Description

This search provides specific SAML access from specific Service Provider, user and targeted principal at AWS. This search provides specific information to detect abnormal access or potential credential hijack or forgery, specially in federated environments using SAML protocol inside the perimeter or cloud provider.

• Type: Anomaly

• Product: Splunk Enterprise, Splunk Enterprise Security, Splunk Cloud

• Last Updated: 2021-01-26
• Author: Rod Soto, Splunk
• ID: bbe23980-6019-11eb-ae93-0242ac130002

Annotations

ATT&CK

ATT&CK

ID	Technique	Tactic
T1078	Valid Accounts	Defense Evasion, Persistence, Privilege Escalation, Initial Access

Kill Chain Phase

• Exploitation

NIST

CIS20

CVE

Search

`cloudtrail` eventName=Assumerolewithsaml 
| stats count min(_time) as firstTime max(_time) as lastTime by requestParameters.principalArn requestParameters.roleArn requestParameters.roleSessionName recipientAccountId responseElements.issuer sourceIPAddress userAgent 
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)` 
|`aws_saml_access_by_provider_user_and_principal_filter`

Macros

The SPL above uses the following Macros:

• cloudtrail
• security_content_ctime

aws_saml_access_by_provider_user_and_principal_filter is a empty macro by default. It allows the user to filter out any results (false positives) without editing the SPL.

Required fields

List of fields required to use this analytic.

• _time
• eventName
• requestParameters.principalArn
• requestParameters.roleArn
• requestParameters.roleSessionName
• recipientAccountId
• responseElements.issuer
• sourceIPAddress
• userAgent

How To Implement

You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs

Known False Positives

Attacks using a Golden SAML or SAML assertion hijacks or forgeries are very difficult to detect as accessing cloud providers with these assertions looks exactly like normal access, however things such as source IP sourceIPAddress user, and principal targeted at receiving cloud provider along with endpoint credential access and abuse detection searches can provide the necessary context to detect these attacks.

Associated Analytic Story

• Cloud Federated Credential Abuse

RBA

Risk Score	Impact	Confidence	Message
64.0	80	80	From IP address $sourceIPAddress$, user agent $userAgent$ has trigged an event $eventName$ for account ID $recipientAccountId$

The Risk Score is calculated by the following formula: Risk Score = (Impact * Confidence/100). Initial Confidence and Impact is set by the analytic author.

Reference

• https://www.cisa.gov/uscert/ncas/alerts/aa21-008a
• https://www.splunk.com/en_us/blog/security/a-golden-saml-journey-solarwinds-continued.html
• https://www.fireeye.com/content/dam/fireeye-www/blog/pdfs/wp-m-unc2452-2021-000343-01.pdf
• https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps

Test Dataset

Replay any dataset to Splunk Enterprise by using our replay.py tool or the UI. Alternatively you can replay a dataset into a Splunk Attack Range

• https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1078/assume_role_with_saml/assume_role_with_saml.json

source | version: 1