Azure Policy Search with Azure Graph

Hi!

In this article, I will show you how you can use Azure Graph to check the result of one specific policy across all the subscriptions of your Azure tenant. Before to start let me refine what’s is it?

Azure Resource Graph (ARG) provides an efficient way to query at scale across a given set of subscriptions for any Azure Resource. If you are not familiar, I will recommend you to spend some time to learn it!

In this example, I will create a query to list all the policy and I will extract the policy name, compliance status and the resource id.

policyresources
| where type == "microsoft.policyinsights/policystates"
| extend name = properties['policyDefinitionName']
| extend state = properties['complianceState']
| extend resourceid = properties['resourceId']
| project name, state, resourceid

In this second example, I will create a query to list the compliance status and the resource id of an existing policy

policyresources
| where type == "microsoft.policyinsights/policystates"
| where properties['policyDefinitionName'] == "Name Of your Azure Policy"
| extend state = properties['complianceState']
| extend resourceid = properties['resourceId']
| project state, resourceid

Maxime.

Disable SAS Key for a Storage Account

Hi,

In this article, I will show you how can disable the SAS Key feature for a Storage Account. When you disallow Shared Key authorization for a storage account, requests from clients that are using the account access keys for Shared Key authorization will fail.

When you are confident that you can safely reject requests that are authorized with Shared Key, you can set the AllowSharedKeyAccess property for the storage account to false.

The AllowSharedKeyAccess property is not set by default and does not return a value until you explicitly set it. The storage account permits requests that are authorized with Shared Key when the property value is null or when it is true.

Azure CLI:

az storage account update \
     --name  \
     --resource-group  \
     --allow-shared-key-access false

Azure Portal:

To check the Shared Key access setting across a set of storage accounts with optimal performance, you can use the Azure Resource Graph Explorer in the Azure portal.

resources 
| where type =~ 'Microsoft.Storage/storageAccounts' 
| extend allowSharedKeyAccess = parse_json(properties).allowSharedKeyAccess 
| project subscriptionId, resourceGroup, name, allowSharedKeyAccess

Maxime.

Azure Sentinel – AAD Use Cases

Hi!

In this article, I will share with you some Azure Active Directory Use Cases created by Microsoft.

Use Case NameDescription
Anomalous sign-in location by user account and authenticating applicationThis query over Azure Active Directory sign-in considers all user sign-ins for each Azure Active Directory application and picks out the most anomalous change in location profile for a user within an individual application. An alert is generated for recent sign-ins that have location counts that are anomalous over last day but also over the last 3-day and 7-day periods.
Azure Active Directory PowerShell accessing non-AAD resourcesThis will alert when a user or application signs in using Azure Active Directory PowerShell to access non-Active Directory resources, such as the Azure Key Vault, which may be undesired or unauthorized behavior.
Attempt to bypass conditional access rule in Azure ADIdentifies an attempt to Bypass conditional access rule(s) in Azure Active Directory.
The ConditionalAccessStatus column value details if there was an attempt to bypass Conditional Access or if the Conditional access rule was not satisfied (ConditionalAccessStatus == 1).
Attempts to sign in to disabled accountsIdentifies failed attempts to sign in to disabled accounts across multiple Azure Applications.
Default threshold for Azure Applications attempted to sign in to is 3.
50057 – User account is disabled. The account has been disabled by an administrator.’
Distributed Password cracking attempts in AzureADIdentifies distributed password cracking attempts from the Azure Active Directory SigninLogs.
The query looks for unusually high number of failed password attempts coming from multiple locations for a user account.
50053 Account is locked because the user tried to sign in too many times with an incorrect user ID or password.
50055 Invalid password, entered expired password.
50056 Invalid or null password – Password does not exist in store for this user.
50126 Invalid username or password, or invalid on-premises username or password.
Explicit MFA DenyUser explicitly denies MFA push, indicating that login was not expected and the account’s password may be compromised.
Failed login attempts to Azure PortalIdentifies failed login attempts in the Azure Active Directory SigninLogs to the Azure Portal. Many failed logon attempts or some failed logon attempts from multiple IPs could indicate a potential brute force attack.
The following are excluded due to success and non-failure results:
0 – successful logon
50125 – Sign-in was interrupted due to a password reset or password registration entry.
50140 – This error occurred due to ‘Keep me signed in’ interrupt when the user was signing-in.
Sign-ins from IPs that attempt sign-ins to disabled accountsIdentifies IPs with failed attempts to sign in to one or more disabled accounts signed in successfully to another account.
50057 – User account is disabled. The account has been disabled by an administrator.
Brute force attack against Azure PortalIdentifies evidence of brute force activity against Azure Portal by highlighting multiple authentication failures and by a successful authentication within a given time window.
(The query does not enforce any sequence – eg requiring the successful authentication to occur last.)
Default Failure count is 5, Default Success count is 1 and default Time Window is 20 minutes.
Password spray attack against Azure AD applicationIdentifies evidence of password spray activity against Azure AD applications by looking for failures from multiple accounts from the same IP address within a time window. If the number of accounts breaches the threshold just once, all failures from the IP address within the time range are bought into the result. Details on whether there were successful authentications by the IP address within the time window are also included.
This can be an indicator that an attack was successful
Successful logon from IP and failure from a different IPIdentifies when a user account successfully logs onto an Azure App from one IP and within 10 mins failed to logon to the same App via a different IP.
This may indicate a malicious attempt at password guessing based on knowledge of the users account.

Maxime.