User Profile
BdCvC
Copper Contributor
Joined 6 years ago
User Widgets
Recent Discussions
Re: Disable users ability to create rules...
My 2 pennies: Cart before the horse? Rules are good, hackers are bad, First stop hackers (MFA, block basic auth, P1 conditional access etc, whatever works for your situation). Run daily reports on successful Logins (are they coming from your offices or from Nigeria), run reports on Failed Logins (has the Hacker community found another way trying to bypass MFA?), train users on phishing techniques. All this can be automated for pennies, and will stop any successful hacks (if they are good enough) within hours or less. Still too long but you can't always win them all. Blocking rules does nothing to help you imho, modern hackers don't even create rules anymore, too obvious. But again, just my opinion. Next month it might all change again, that's the fun of it....16KViews2likes0CommentsRe: Login failed with Sign-in was blocked because it came from an IP address with malicious activity
c___b Not an authorative answer, just an observation based on 30 Tenants. We see these messages coming from all over the world (Asia seems prevalent), targeting our users with IMAP4 calls, some are bulk and block the account, some come from suspect IPs (MS machine learning we assume) and some just try 3 times per hour (to prevent blocking the account we assume). These are all Failures (we also monitor successful Logins are only from locations we expect). To block these Fails we advise to enable MFA. For those tenants that refuse to have MFA enabled (yes it happens) we disabled Basic authentication (iMap4 and Pop3 mainly) though [Set-OrganizationConfig -DefaultAuthenticationPolicy] to stop these password guessing attempts. We also did this for Tenants who are not (yet) being targeted. For new Tenants we don't give a choice anymore, MFA is included.52KViews0likes0CommentsRe: Why are Microsoft Data Centres logging in to my Office 365 accounts? Activity Alerts - BAV2ROPC
bobster95 We started setting up Authentication Policies to disable Basic Auth (ahead of MS MC204828 mid 2021), but came across the following challenges in doing so, it may help others in their attempt to secure their Tenants (and hopefully stop BAV2ROPC occurring/logging): Some admins were using PowerShell scripts and we had to exclude those individuals from the Policies. Also had to exclude users that were still using IMAP, POP3 and/or old phones configured with Exchange Activesync (in stead of the more secure O365 account) setup. And then there were the few using Office2013 (I know!) that could not upgrade as yet, and needed a Registry Hack or exclusion again.21KViews0likes0CommentsRe: Why are Microsoft Data Centres logging in to my Office 365 accounts? Activity Alerts - BAV2ROPC
Aquilius My personal opinion and experience is that useragent=BAV2ROPC from ISP=Microsoft IP addresses (only) are failed login attempts (including from deleted userids), but are still logged in the Azure Logs, and thus causing a false positive. On several blogs I have read that even MS is recommending to ignore these. I have never encountered a hack based on these, but have seen hacks on everything else (not BAV2ROPC from MS IP's). I am monitoring every 4 hours across 30 Tenants, 2 -400 users varying across 5 countries22KViews0likes3CommentsRe: Why are Microsoft Data Centres logging in to my Office 365 accounts? Activity Alerts - BAV2ROPC
BdCvC MS has fixed the Azure log feed into UnifiedAuditLogs last week, which gave me the opportunity to look at the Azure logs (the source logs) in depth again, which confirmed that the False Positive is already present in the Azure UserLogin logs. Unfortunately the Azure logs content itself proves no better, even worse as the (MS internal) IP lookup does not even identify/log their own datacentres (so you have something to filter on). So I am back to extracting the UnifiedAuditLog, running it by an IP lookup and ignoring ISP=Microsoft Data Centres, as these are all false positives. Have managed to catch several hacked accounts this way, if customers would only pay the eu5 extra for P1, so we can use MFA (and Registered Locations) and the likes as prevention is always better than detection after the hack has already taken place.43KViews0likes11CommentsRe: Why are Microsoft Data Centres logging in to my Office 365 accounts? Activity Alerts - BAV2ROPC
Alicia_Shelley Interesting new development, UnifiedAuditLogs in Europe have failed to update UserLoggedin records since around 25/11/2020, logged a case with MS, have seen AZ auditlogs re-feed old data to unifiedauditlogs but username is not the email address but the SID, so this looks like they have a problem and a bug. I added a P1 lic to one of my 12 Tenants and checking Get-AzureADAuditSignInLogs in stead, will let you know if this is more accurate regarding the incorrectly recorded MS sites.45KViews0likes12CommentsRe: Why are Microsoft Data Centres logging in to my Office 365 accounts? Activity Alerts - BAV2ROPC
casualbob I am monitoring the audit logs of a few dozen Tenants via PowerShell and see ISP = Microsoft coming from more and more locations (as MS is implementing more IP's in their Data Centers). I have excluded Microsoft* ISP's from my Alerts, as these are likely just password hackers and the logs interpret/file them as successful Logins, in stead as Attempts. If they were truly actual logins, we would not be in business anymore 🙂 https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth-ropc We trap many real password breaches (users are users) this way (MFA seems too expensive here), but none were ever related to ROPC instances. Hope that helps, not a factual conclusion, just an interpretation of what we are experiencing.52KViews2likes0CommentsRe: Why are Microsoft Data Centres logging in to my Office 365 accounts? Activity Alerts - BAV2ROPC
casualbob I have started ignoring below sources, as I could not link them to password hacks. They also appeared for users I deleted ages ago, and the logs still say a successful UserLogin, so may be an internal error. ID IP Description RegionName Country 30 40.101.126.245 Microsoft Germany 31 40.101.71.117 Microsoft Austria 32 40.101.124.253 Microsoft Netherlands 33 40.101.100.133 Microsoft United States 34 40.101.126.173 Microsoft Finland 35 52.98.40.37 Microsoft South Korea The number of actual hacked accounts appear to become smaller in Q1 2020, we still see a few occasionally but not as much as Q3 and Q4 last year.59KViews1like6Comments
Recent Blog Articles
No content to show