-
Notifications
You must be signed in to change notification settings - Fork 502
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Rule Tuning] Attempts to Brute Force a Microsoft 365 User Account #2278
Comments
Hey @baserock, thanks for bringing this issue up. Can you attach a sample redacted event? |
Of the event I tuned out? or the events I want to retain? |
Sample event I am tuning out: |
Please note that username does not exist in this event and the threshold aggregation on field 'user.id' has a value of "not_available". This event is unhelpful from a purely username brute force attempt rule. I haven't figured out if the absence of username is a logging error or an event type/source discrepancy (from Microsoft) and I honestly can't waste more time differentiating it. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Hello, I am however seeing what seems like the events are acutally connected to specific user, but for some reason o365 does not log this user.id. The o365.audit data does contain the same ID for all the logs,
Event with user.id="Not available":
Would be great to know what these numerous logs with user.id "Not available" are and what is causing them and also how to exclude them from the Elastic alerts. |
HI, it seems that with the new ES|QL version of the rule the case of the user "Not available" it is solved |
## Link to rule
Description
This rule is designed to detect brute force of a Microsoft 365 user account. Specifically this rule is engineered to detect a username being attempted repeatedly, It does not account for API key access attempts. Brute force attempts that do not contain usernames continue to create false positives under this rule. Which are not aligned with the detection intentions of this rule.
I recommend restricting the captured data set to only contain values where a username exists in the first place. In the KQL which this rule is written this would be
user.name: *
This appears to work as expected and intended in our testing.
Example Data
Recommended Rule Change:
event.dataset:o365.audit and event.provider:(AzureActiveDirectory or Exchange) and event.category:authentication and event.action:(UserLoginFailed or PasswordLogonInitialAuthUsingPassword) and user.name: * and not o365.audit.LogonError:(UserAccountNotFound or EntitlementGrantsNotFound or UserStrongAuthEnrollmentRequired or UserStrongAuthClientAuthNRequired or InvalidReplyTo)
The text was updated successfully, but these errors were encountered: