Command & Control

Azure AD Suspicious Access from Cloud Provider

Azure AD Suspicious Access from Cloud Provider

Detection overview

The "Azure AD Suspicious Access from Cloud Provider" detection alerts security teams to logins to Azure AD accounts from cloud provider IP addresses that are unusual for that account. This detection can indicate an attacker attempting to mask their location by using public cloud services, such as AWS, GCP, or Azure, to gain unauthorized access and further conceal their true source.

Triggers

  • An account has been accessed successfully from a public cloud IP, e.g. AWS, Azure, GCP which is unusual for this account.
  • Vectra’s AI will continuously learn whether a cloud provider and region are normal for a given user based on their history.

Possible Root Causes

  • An attacker has successfully logged into an account using a public cloud IP. The attacker has used a public IP to hide their true location and appear from a normal geolocation and IP space.
  • A user or a user connected software has successfully logged into an account from a public cloud IP provider and region for the first time. The user may be actively using the cloud provider for a legitimate business function, or a cloud host software associated with the account has connected.

Business Impact

  • An attacker who has access to an internal account can access any connected applications and progress their attack.

Steps to Verify

  • Review whether the account owner would have a reason to be accessing their account from a public cloud.
  • Consult the available logs to determine if there has been any attack progression. • Reach out to the account owner to confirm that they were behind the sign-in event
Azure AD Suspicious Access from Cloud Provider

Possible root causes

Malicious Detection

An attacker, having compromised a valid account, may use a public cloud IP to obscure their true location and avoid detection. This method provides the attacker with a level of anonymity, allowing them to operate as though they are within the legitimate cloud environment while potentially bypassing location-based restrictions.

Benign Detection

Legitimate users or applications may access Azure AD from a cloud provider IP address due to routine use of cloud services or the presence of legitimate software hosted on these platforms. For example, a developer accessing corporate resources from a managed cloud environment may trigger this detection if the behavior is newly introduced.

Azure AD Suspicious Access from Cloud Provider

Example scenarios

1. Unexpected Cloud-Based Access Attempt

A user account linked to a specific geographic region logs in from a cloud provider IP located in another region. This deviation might indicate unauthorized access.

2. Access from a Cloud Provider After Account Compromise

Following an account compromise, an attacker utilizes cloud provider IPs to maintain access, attempting to bypass location-based detection measures.

Azure AD Suspicious Access from Cloud Provider

Business impact

If this detection indicates a genuine threat, the organization faces significant risks:

Obscured attacker presence

Attackers using cloud IPs can blend into routine traffic patterns, making detection challenging and allowing for sustained, covert access.

Risk of data compromise

Unauthorized access through this method may expose sensitive data, leading to confidentiality breaches and possible data exfiltration.

Compliance violation potential

Unauthorized logins via cloud IPs can lead to non-compliance with data security policies, increasing the risk of regulatory penalties.

Azure AD Suspicious Access from Cloud Provider

Steps to investigate

Azure AD Suspicious Access from Cloud Provider

MITRE ATT&CK techniques covered

FAQs

Why would a cloud provider IP be suspicious?

How does this detection help identify suspicious activity?

Could legitimate cloud services trigger this detection?

What should I do if this detection is triggered?

How can attackers leverage cloud provider IPs?

Could this detection indicate a policy violation?

Is the account necessarily compromised if this detection occurs?

What data should be reviewed in this situation?

What further actions are advisable if compromise is confirmed?

How does Vectra’s AI help in detecting these patterns?