Possible Forest Blizzard attempted credential harvesting - Sept 2020

[jonbprogramming]

Describe the bug
I was researching an issue a customer had with running the "Possible Forest Blizzard attempted credential harvesting - Sept 2020" (id: 04384937-e927-4595-8f3c-89ff58ed231f) OOTB query. I discovered that the "RecodType" column references should be represented by 9 for "AzureActiveDirectoryAccountLogon” (also deprecated) and the "AzureActiveDirectoryStsLogon" as “15”. Also, the query references “UserLoggedIn” which I was unable to find in my test tenant and think this may be accomplished with a join to the “SignIn” logs table.

Query Referenced (Possible Forest Blizzard attempted credential harvesting - Sept 2020)
let IPs = dynamic (["199.249.230.","185.220.101.","23.129.64.","109.70.100.","185.220.102."]);
OfficeActivity
| where RecordType in ("AzureActiveDirectoryAccountLogon", "AzureActiveDirectoryStsLogon")
| where Operation != 'UserLoggedIn'
| extend UserAgent = iff(parse_json(ExtendedProperties)[0].Name =~ "UserAgent", extractjson("$[0].Value", ExtendedProperties, typeof(string)),"")
| mv-expand parse_json(ExtendedProperties)
| where ExtendedProperties.Name =~ "RequestType"
| extend RequestType = ExtendedProperties.Value
| where ClientIP has_any (IPs)
| summarize authAttempts=dcount(TimeGenerated), firstAttempt=min(TimeGenerated), lastAttempt=max(TimeGenerated), uniqueIPs=dcount(ClientIP), uniqueAccounts=dcount(UserId), attemptedAccounts=make_set(UserId) by UserAgent
| where authAttempts > 2500
| extend timestamp = firstAttempt
| sort by uniqueAccounts

https://learn.microsoft.com/en-us/office/office-365-management-api/office-365-management-activity-api-schema
https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/officeactivity

To Reproduce
Steps to reproduce the behavior:

1. Run the following query and it should produce no records:
   OfficeActivity
   | where RecordType in ("AzureActiveDirectoryAccountLogon", "AzureActiveDirectoryStsLogon")
   | where Operation != 'UserLoggedIn'

2. If you add a numerical value for a RecordType that exists in your LA space records will be returned. Example:
   OfficeActivity
   | where RecordType in ("50")
   | where Operation != 'UserLoggedIn'

3. The query ran to look for 'UserLoggedIn' activity. None was returned:
   OfficeActivity
   | distinct Operation
   | sort by Operation

Expected behavior
I would expect that running the following would return records:
OfficeActivity
| where RecordType in ("AzureActiveDirectoryAccountLogon", "AzureActiveDirectoryStsLogon")
| where Operation != 'UserLoggedIn'

[github-actions]

Thank you for submitting an Issue to the Azure Sentinel GitHub repo! You should expect an initial response to your Issue from the team within 5 business days. Note that this response may be delayed during holiday periods. For urgent, production-affecting issues please raise a support ticket via the Azure Portal.

[github-actions]

Thank you for submitting an Issue to the Azure Sentinel GitHub repo! You should expect an initial response to your Issue from the team within 5 business days. Note that this response may be delayed during holiday periods. For urgent, production-affecting issues please raise a support ticket via the Azure Portal.

[github-actions]

Thank you for submitting an Issue to the Azure Sentinel GitHub repo! You should expect an initial response to your Issue from the team within 5 business days. Note that this response may be delayed during holiday periods. For urgent, production-affecting issues please raise a support ticket via the Azure Portal.

[github-actions]

Thank you for submitting an Issue to the Azure Sentinel GitHub repo! You should expect an initial response to your Issue from the team within 5 business days. Note that this response may be delayed during holiday periods. For urgent, production-affecting issues please raise a support ticket via the Azure Portal.

[v-sudkharat]

Hello @jonbprogramming, thanks for flagging this issue, we are working on this, will update you shortly, thanks!

[github-actions]

Thank you for submitting an Issue to the Azure Sentinel GitHub repo! You should expect an initial response to your Issue from the team within 5 business days. Note that this response may be delayed during holiday periods. For urgent, production-affecting issues please raise a support ticket via the Azure Portal.

[v-muuppugund]

Hello @jonbprogramming, thanks for flagging this issue, we are working on this, will update you ASAP

[v-sudkharat]

Hello @jonbprogramming, we are working on this issue, and an update will be given shortly. Thanks

[rahul0216]

Hi @jonbprogramming, Thank you for reporting the issue, really appreciate it.
We verified the rule and yes, as you mentioned it doesn't work as expected. Apart from the missing RecordType, IoCs (In this case IPs) are also stale and no longer valid. So we have decided to deprecate this rule.

There are rules to detect Brute Force and Password Spray attacks in Azure Active Directory Solution, which can be used to detect similar attacks. User can use those to cover this scenario.

[v-muuppugund]

@jonbprogramming Gentle reminder,Could you please look in to the steps provided by us and let us know if any other information required

Hi @jonbprogramming, Thank you for reporting the issue, really appreciate it. We verified the rule and yes, as you mentioned it doesn't work as expected. Apart from the missing RecordType, IoCs (In this case IPs) are also stale and no longer valid. So we have decided to deprecate this rule.

There are rules to detect Brute Force and Password Spray attacks in Azure Active Directory Solution, which can be used to detect similar attacks. User can use those to cover this scenario.

[jonbprogramming]

Sounds good. I will relay this to the customer.

[hbrum3]

Hey everyone, just wanted to ask how a rule being deprecated may come across to the customer? This query is deployed in our environment and doesn't show any markers or indications that it is deprecated