How to make Rule "Explicit MFA Deny" better?

%3CLINGO-SUB%20id%3D%22lingo-sub-2161212%22%20slang%3D%22en-US%22%3EHow%20to%20make%20Rule%20%22Explicit%20MFA%20Deny%22%20better%3F%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2161212%22%20slang%3D%22en-US%22%3E%3CP%3EHello%2C%3CBR%20%2F%3E%3CBR%20%2F%3EWe%20turned%20on%20this%20rules%20for%20weeks.%20But%20all%20the%20incidents%20from%20the%20rule%20seem%20to%20benign.%3CBR%20%2F%3EThe%20query%20is%20as%20follows%3A%3CBR%20%2F%3E%3CBR%20%2F%3ESigninLogs%3CBR%20%2F%3E%7C%20where%20ResultType%20%3D%3D%20500121%3CBR%20%2F%3E%7C%20where%20Status%20has%20%22MFA%20Denied%3B%20user%20declined%20the%20authentication%22%3CBR%20%2F%3E%7C%20extend%20AccountCustomEntity%20%3D%20AlternateSignInName%3CBR%20%2F%3E%7C%20extend%20IPCustomEntity%20%3D%20IPAddress%3CBR%20%2F%3E%7C%20extend%20URLCustomEntity%20%3D%20ClientAppUsed%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EOur%20idea%20is%20check%20the%20previous%20login%20IP%20or%20deviceid%20of%20devicedetail.%3C%2FP%3E%3CP%3EIs%20there%20any%20other%20suggestion%20or%20comment%3F%3CBR%20%2F%3EThanks%20a%20lot%3CBR%20%2F%3E%3CBR%20%2F%3E%3CBR%20%2F%3E%3CBR%20%2F%3E%3CBR%20%2F%3E%3CBR%20%2F%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-2173262%22%20slang%3D%22en-US%22%3ERe%3A%20How%20to%20make%20Rule%20%22Explicit%20MFA%20Deny%22%20better%3F%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2173262%22%20slang%3D%22en-US%22%3EThanks%20for%20the%20question.%20Are%20you%20looking%20to%20see%20if%20there%20was%20a%20successful%20MFA%20before%20this%3F%20If%20so%2C%20you%20can%20check%20for%20success%20and%20likely%20the%20IP%20would%20be%20a%20good%20place%20to%20start.%20This%20hunting%20query%20shows%20how%20to%20use%20an%20anti-join%20to%20exclude%20previous%20logons%20-%20%3CA%20href%3D%22https%3A%2F%2Fgithub.com%2FAzure%2FAzure-Sentinel%2Fblob%2Fmaster%2FHunting%2520Queries%2FSigninLogs%2Fnew_locations_azuread_signin.yaml%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%22%3Ehttps%3A%2F%2Fgithub.com%2FAzure%2FAzure-Sentinel%2Fblob%2Fmaster%2FHunting%2520Queries%2FSigninLogs%2Fnew_locations_azuread_signin.yaml%3C%2FA%3E%20-%20it%20is%20based%20on%20location%2C%20but%20you%20can%20apply%20the%20same%20concept%20to%20IP.%20I%20would%20be%20careful%20about%20how%20far%20you%20look%20back.%20You%20may%20also%20want%20to%20compare%20AppDisplayName%20to%20make%20sure%20it%20is%20the%20same%20app%20and%20also%20look%20at%20MfaDetail%20to%20confirm%20the%20authmethod.%3C%2FLINGO-BODY%3E
New Contributor

Hello,

We turned on this rules for weeks. But all the incidents from the rule seem to benign.
The query is as follows:

SigninLogs
| where ResultType == 500121
| where Status has "MFA Denied; user declined the authentication"
| extend AccountCustomEntity = AlternateSignInName
| extend IPCustomEntity = IPAddress
| extend URLCustomEntity = ClientAppUsed

 

Our idea is check the previous login IP or deviceid of devicedetail.

Is there any other suggestion or comment?
Thanks a lot





 

1 Reply
Thanks for the question. Are you looking to see if there was a successful MFA before this? If so, you can check for success and likely the IP would be a good place to start. This hunting query shows how to use an anti-join to exclude previous logons - https://github.com/Azure/Azure-Sentinel/blob/master/Hunting%20Queries/SigninLogs/new_locations_azure... - it is based on location, but you can apply the same concept to IP. I would be careful about how far you look back. You may also want to compare AppDisplayName to make sure it is the same app and also look at MfaDetail to confirm the authmethod.