New clients MFA is all out of whack and not sure how to fix it.

[thecomputerguy]

Sorry about the length of this message...

I took on a new Insurance company the absorbed the original insurance company I worked with (they didn't have IT support). My client merged with this and is now double the size (25 users).

I'm not really sure what to do here.

I added most of my clients into this tenant with their new email addresses and forwarded everything from my original clients tenant to this new tenant (enabled external forwarding with auto-reply until we can eventually kill it).

New company gave me a global admin account so I could accomplish all of this.

Prior to adding the emails a couple things I saw was that they had security defaults disabled, and they were using per user MFA (sorta). This also means legacy protocols are still enabled like POP, IMAP, and SMTP Auth. Their "admin employee" setup a couple of our users and I setup the rest. The ones I setup I enabled per user MFA because I wasn't about to botch the whole system since this turned into a "rush" merger and I was unfamiliar with the tenant. The "admin employee" did not enable per user MFA for a couple of our people.

Now I've gotten two phone calls of suspicious emails and I'm on a wild goose chase, especially being the "new" IT guy, and now I'm the one that gets to deal with this stuff, yay me.

The 1st one was one of our people who did not have per user MFA enabled (I didn't set this user up). I did not see any bad sign-ins in Azure in this particular case but I changed the users password, enabled per user MFA and sent her off. Maybe I'm looking in the wrong place.

The 2nd one now is one of "their" people. Apparently she sent an email to a client, CC'd one of our people. Our people received the email correctly. The client received all of the correct header information, and even included our person in the CC but the reply to was changed to some spam email, and the body of the email was changed to a "you won a free gift card!".

Basically internally we see successful delivery of:

From: us@company.com
To: client@yahoo.com
CC: us2@company.com
Subject: Here is your quote
Body: Everything is fine

The client received:

From: us@company.com
To: client@yahoo.com
CC: us2@company.com
Replyto: spam@scammer.com
Subject: Here is your quote
Body: You won a free gift card!

We did not get CC'd on the spam email we received the CORRECT email at the CORRECT time.

The weird thing is I did a message trace and the message trace looks totally fine and was sent at 5:43PM from the correct person. The message trace shows NO indication of the spam email, unless I guess if it was somehow sent through SMTP invisibly?

The client forwarded the spam email to them, then they forwarded to me (in panic) and shows that the message was sent at 5:43PDT (so the exact same time) and I find that impossible.

It's almost like this email was intercepted in transit, and the body was changed, or the clients email is compromised and stripped and changed the body. This is a new one for me, I have no idea.... but the clients email is @yahoo.com

This happened about 5 days ago and there has been nothing done (I just heard about it), and there has been no further issue.

Bigger issues we have here are:

This sending user does not have per-user MFA enabled (along with about another 15 users).
The tenant does not have security defaults enabled.
Per-User MFA is not enabled for everyone.
POP, IMAP, SMTP are all still enabled for all users.
No DMARC
No DKIM
SPF is just the standard O365 record (v=spf1 include:spf.protection.outlook.com -all)

I feel like their client is the one compromised here. They re-forwarded the email to the client and he received it fine.

Beyond this issue what is the correct way to lock this thing up?

- Add the DKIM and DMARC records
- Disable per-user MFA for EVERYONE
- Reset everyone's password to a temp password and carrier Pidgeon it over to them
- Enable security defaults
- Re-do MFA across the board?

UGHHHHHHHHHH HALP IM LOSING MY MIND I DON'T HAVE TIME FOR A MERGER RIGHT NOW

@YeOldeStonecat @Sky-Knight

 

[Sky-Knight]

Ok so... here's the thing.

Security Defaults gets turned on... NOW. Any other pathway forward gets you sued. The only time it's acceptable to disable security defaults is when you're deploying conditional access.

Everyone gets MFA, if they want to make exceptions, they buy Premium so they get Conditional Access.

SO the first think you do is check their licensing, do they have Premium? If no... then no Conditional access and Security Defaults is turned on.

Then you do the rest of this:

Log into tenant with Global Admin AD credentials
1. Ensure Security Default is enabled (Azure)
2. In Azure, search for Authentication Methods, click the Azure AD Authentication Methods applet.
3. Select policies and enable Microsoft Authenticator, SMS and OATH for all users.You can also add any additional methods from the legacy Per-User MFA system settings (admin center MFA).
You can also add any additional methods from the password reset authentication methods in Azure (Protect and Secure -> Password reset -> Authentication Methods)
4. Click manage migration in the middle of the screen and select "Migration in progress"
5. In Microsoft 365 Admin Center, search MFA and select Multi-factor authentication settings
6. Click Configure multi-factor authentication
7. Disable all accounts.
8. Click service settings at the top and remove all verification options and save
9. In Azure, Search for Azure AD and click "Azure Active Directory" then password reset and then authentication methods
10. uncheck all methods and click save. (Except perhaps Security Questions, but I don't recommend these either)
11. Click Authentication methods under Protect & secure on the left
12. Click manage migration
13. Click Migration complete
14. Sign out

Now go through every account, in Azure AD and check authentication methods for things that are wrong, and be seriously tempted to just remove all authenticators from all accounts, and click the box to reenroll the authenticators at the top.

Then move on to the DNS fixes you just reported.

If the users complain, FIRE THEM.

I'm DEAD SERIOUS FIRE THEM! The liabilities are getting hard and rough, and not a single soul on this board can any longer afford to not be living up to basic standards.

If they're still around after all that, sit down with the user that owns the infected mailbox and use the WEB VERSION of Outlook to check for rules, they've got one... and it's mucking with the flow.

You might also consider looking at the Exchange admin panel for mail flow rules too. Assuming the Global Admin was breached at some point... which given all this is QUITE possible.

But seriously, once again... do not give them any choice about MFA. It's on by default for a reason, MS will force the issue in Sept, rip off the bandage and get it over with.

And... if all else fails... I'm no longer in the MSP business I'm full time working for a much larger org designing Azure fun stuff. So, PM me and we'll see if I can connect to peek over your shoulder once. This process isn't hard, but everyone that admin's M365 needs to know it.

 

[thecomputerguy]

Ok so... here's the thing.

Security Defaults gets turned on... NOW. Any other pathway forward gets you sued. The only time it's acceptable to disable security defaults is when you're deploying conditional access.

Everyone gets MFA, if they want to make exceptions, they buy Premium so they get Conditional Access.

SO the first think you do is check their licensing, do they have Premium? If no... then no Conditional access and Security Defaults is turned on.

Then you do the rest of this:


Now go through every account, in Azure AD and check authentication methods for things that are wrong, and be seriously tempted to just remove all authenticators from all accounts, and click the box to reenroll the authenticators at the top.

Then move on to the DNS fixes you just reported.

If the users complain, FIRE THEM.

I'm DEAD SERIOUS FIRE THEM! The liabilities are getting hard and rough, and not a single soul on this board can any longer afford to not be living up to basic standards.

If they're still around after all that, sit down with the user that owns the infected mailbox and use the WEB VERSION of Outlook to check for rules, they've got one... and it's mucking with the flow.

You might also consider looking at the Exchange admin panel for mail flow rules too. Assuming the Global Admin was breached at some point... which given all this is QUITE possible.

But seriously, once again... do not give them any choice about MFA. It's on by default for a reason, MS will force the issue in Sept, rip off the bandage and get it over with.

And... if all else fails... I'm no longer in the MSP business I'm full time working for a much larger org designing Azure fun stuff. So, PM me and we'll see if I can connect to peek over your shoulder once. This process isn't hard, but everyone that admin's M365 needs to know it.

Wow, thank you for the information. I am going to start looking at this tenant right now. I might have to take you up on your offer on some guidance. I have a couple scenarios that I wanted to ask about before I try to goto bed that maybe you can verify.

Key:
PUMFA = Per user MFA
SD = Security defaults

1.) No PUMFA enabled, no SD enabled, migration not complete
Result: Single-Factor authentication & weak tenant

2.) PUMFA enabled, no SD, migration not complete
Result: PUMFA & weak tenant

3.) PUMFA enabled, SD enabled, migration not complete
Result: PUMFA & stronger tenant, but no AD MFA.

4.) Migration complete, AD MFA enabled, SD enabled
Result: AD MFA (Best Practice), stronger tenant

What happens if you don't disable PUMFA for all prior to migration?
What happens if you disable all BUT 1 single account prior to migration
Can you even enable PUMFA after the migration is complete? What happens?

I know I will for sure have some other questions but I wanted to get these out asap.

I'm going to try this on my test tenant as early as I can tomorrow. I'm realizing I think I have more than a few tenants that need to be hit with this bomb.

 

[callthatgirl]

@Sky-Knight I have a 11 mbx migration coming up and was going to turn off security to do bittitan and all the Outlook setups, this is gone now? So I have to do all the phones and work with each user say no plz

 

[thecomputerguy]

@Sky-Knight I have a 11 mbx migration coming up and was going to turn off security to do bittitan and all the Outlook setups, this is gone now? So I have to do all the phones and work with each user say no plz

OH MY GOD BRUTALLLL

I just did a migration from Gsuite into an empty unused tenant and had SUCH a hard time getting it working even with security defaults and 2FA/MFA disabled.

Getting with working with ModernAuth just STINKS with Gsuite

However ... disabling security defaults still appears to be there in all my tenants.

 

[YeOldeStonecat]

Oh boy...well, yeah I agree with Rob....at the very least. flip on "Security Defaults"..it's better than nothing. Security Defaults do the following:
*Requires all users to register for MFA...2x week grace period
*Forces Admin accounts to always MFA
*Blocks legacy auth protocols
*Protects Azure portal access
**And..here's the part that's "better than nothing, but still not NEEEEEEEEARLY as good as CA. "Requires uers to perform MFA when necessary".

...now...focus on "when necessary". It's very...obscure. I've not seen any hard facts about what initiates MFA for standard users when SD is enabled, but I've read a few "sorta uses". It will apply some smarts from a "lite" version of "risky logins"...and often do it for any "unregistered devices" with new logins. So, sometimes under certain conditions it will prompt for MFA, other times....it can turn a blind eye. So, IMO, it's not nearly as good as conditional access, it's not a "100 %" thing. Yes...it's better than nothing.

So, you have this insurance company...merged with another, with an unknown history of the 365 tenant.

Here's a list of things I would do. And...you have a LOT of homework here.
*Insurance companys themselves have security standards to follow, their own carrier will have requirements. My big insurance company client...their insurance REQUIRES MFA at the computers. Yup..for Windows login. Your client here likely ...errr....hopefully...has someone who can find this answer. Certainly MFA for their 365 stuff...yup. But I'm talking about for the Windows login...MFA for that. Also MFA on the server, MFA on network equipment management interfaces, etc.

RE: the 365 tenant. for end users, I would 100% insist on M365BizPrem licensing for all. I'd 100% walk away if they did not accept that, I would not want to own that wide open headache.
*I'd create my own global admin account. I always do that, and I delete the "original" admin/administrator account that is created when the tenant is born. I never leave a username account called "admin" or "administrator". Once I have my own account created, and it's a global admin, and I add my delegated Microsoft account partner access...I then delete the original admin account(s).
*I would purchase and add a EMS E5 license and assign to my global admin account. This unlocks a lot of additional features you don't even see in Azure P1. Additional more granular categories under the "risky" login category. Just allows you even more insight into the tenant, additional eyes on OAuth tokens, etc.

If you're managing 365 tenants for your clients, Microsofts "Lighthouse for 365" requires BizPrem or higher licensing in the tenant so it can peek in and provide you with those helpful dashboard alerts. Won't work with the basic insecure useless "Standard" licenses. You need at least 1 BizPrem or higher license in the tenant for Lighthouse to work...but ignore that "at least 1" statement, there are kajillions of additional reasons you should have each and every regular user of each and every tenant of yours using a BizPrem license. I realize there are simple needs for "online only" licenses, however I still add an "ATP/Defender" license on top of those....and for some clients, it's still helpful to add an Intune license on top of those also...And an AzureP1 license....and...now we're back nearly to the price of a BizPrem license.

Users you suspect of having their account poached in the past. Changing the password often isn't enough. There's a "Sign this user out of all Microsoft 365 sessions" button there...use it. And THEN change the password, enroll MFA, and get them signed into their devices again.

 

[Sky-Knight]

@Sky-Knight I have a 11 mbx migration coming up and was going to turn off security to do bittitan and all the Outlook setups, this is gone now? So I have to do all the phones and work with each user say no plz

No actually you don't...

I've made this mistake too, far too many times and the new shop I'm working for just hands people instructions and tells them to deal with it. From the very first day it's full stop, put on your big boy or girl pants, and be responsible for your own junk OR we're going to bill 3 hours per phone for personal hand holding. (@$180/hr I might add)

You can put that provision worded however you like in your agreement, and you can let the business decide if your time will be paid or not. Either way, you win!

Sadly, Bittitan does require single factor, and you cannot make that work without Conditional Access or disabling security defaults.

The GOOD NEWS IS assuming the tenant has the auth configured correctly, the accounts with MFA will continue to use it, while the account without can do its job, so when you flip the switch again not much changes.

P.S. because Microsoft is STUPID. If you want Universal MFA and you don't have Conditional Access, Security Defaults + Authentication Methods isn't enough. You must also hit the devices blade in Azure AD and find the switch there to require MFA on AAD join. Which is yet another thing that has to be turned OFF once you upgrade to Conditional Access.

 

[YeOldeStonecat]

Adding notes, this client still have an on-prem server? Or have they gone "all cloud"..if so, AzureAD join all devices.

Also, work towards getting Conditional Access going for all users, however....due diligence ahead of time....for those legacy protocols
*Many insurance agencies have a "contact us" mail form on their website. If so, SMTP2GO.
*Many insurance agencies use software that has its own SMTP engine, like Applied Systems/Epic, ...SMTP2GO time for that. They will not speak modern auth, they need legacy auth. App Passwords are about to be a thing of the past (already happening).
*MFPs...set up to scan to a Teams channel that is mail enabled...also SMTP2GO.

So...get a hold of DNS cpanel, get those DKIM records created, and the records for SMTP2GO if using that. DMARC too, I just do =quarantine Nothing else.

 

[YeOldeStonecat]

Robs reply above got me to thinking....much like many detailed admins did with local domain controllers, eyeball the list of joined computers....and delete "old ones". Now with 365 and the fact that many users can/could self register devices...and some might have had the smarts to self join devices...pour through that list, and look for devices that were "registered" or "joined"..and remove 'em. Not just computers, but other devices like phones. Yup this can involve going around the room of your client and finding out what each user has for a phone.

And like Rob said above, don't leave those settings open for a user being able to join without MFA.

Now, also while in the Azure Admin portal,gl through their Enterprise Applications...and look for weird apps they don't use in there that may have manually be added. Yes...be careful, don't want to remove the wrong thing. But...there may be one or two that stick out like a sore thumb. You can often drill into the properties of an app and see who set it up. Can go from there.

I turn off allowing users to consent to enterprise apps. If they need to register an app with the tenant, they can reach out to you, you can register it, or turn off that setting for an hour.

There are settings to disable forwarding to external resources for mailboxes. Rob covered what else to look for on suspected user mailboxes.....you have local Outlook rules but bad actors usually do it at the mailbox level which you see via OWA, can't see those rules via Outlook.

 

[nlinecomputers]

There are some PowerShell scripts to run on compromised mailboxes.

Office365/AD-365 Compromised Account Procedure.ps1 at master · Scine/Office365

Office 365 Powershell scripts. Contribute to Scine/Office365 development by creating an account on GitHub.

github.com

 

[nlinecomputers]

And this.

Investigating an Office 365 account compromise

I’m starting to get lots of questions about how to determine when exactly an Office 365 account was compromised. Typically, the two most common compromises are phishing and weak passwords. This art…

blog.ciaops.com

 

[callthatgirl]

@Sky-Knight Thanks for the info, I just got some decent instructions from my vendor on how to prepare for the migration. I'll make a TLDR for myself and will share here. I also have plans to make a lot of DYI instructions for the clients and maybe a video. Migration work is $299 an hour and while I love a big final invoice....it's time. I'm in a busy period and while I might lose on a big project, my little day to day jobs bring in more projects.

 

[thecomputerguy]

This whole post is really spiking my imposter syndrome today.

 

[callthatgirl]

@thecomputerguy this whole post excites me, I have been turning away larger migrations for years, only doing under 10 users. I figured it was time to get back in the game, hoping to do 50 and under now.

So it was helpful for me, take time to make your own documentation from what you read here. I saved this post so I can use it over the weekend.

 

[thecomputerguy]

@Sky-Knight @YeOldeStonecat

Ok I think I'm getting an idea of how this is supposed to work. Can you help me answer these questions?

3. Select policies and enable Microsoft Authenticator, SMS and OATH for all users. You can also add any additional methods from the legacy Per-User MFA system settings (admin center MFA).
Is this done to allow Azure to accept the legacy MFA data into the Azure Authentication methods? It seems like this step could be skipped (I wont for now), since you also recommend potentially removing this data that is being migrated per:

@Sky-Knight Now go through every account, in Azure AD and check authentication methods for things that are wrong, and be seriously tempted to just remove all authenticators from all accounts, and click the box to reenroll the authenticators at the top.

Does this determine what authentication methods users are allowed to use for MFA per azure? If it does then why don't I see the option for SMS when I attempt to login as a new user and are prompted to setup MFA?


Per here:

Now go through every account, in Azure AD and check authentication methods for things that are wrong, and be seriously tempted to just remove all authenticators from all accounts

Is there a way as an admin for me to remove an authenticator a user has registered? Where?


Is there a way to allow SMS as a method of MFA? My only initial options are to use the Microsoft Authenticator or a "different authenticator app" even though I have all of the options you stated above enabled? I know this is less secure but sometimes my clients employees don't even speak English well.




Is there a way to disable push based notification approval MFA and require a OTP from users Authenticator?
I've heard here multiple times that people are dumb and approve anything that pops up on their phone.

 

[thecomputerguy]

What in the ACTUAL HECK?

I did everything above. As a test registered a test user in my test tenant with the MS authenticator. Then approved the login and got into the users account.

Then as a test I closed out, opened a new incognito window and logged in and it allowed me to login without having to use MFA? Azure logs show Authentication requirement as "Single-Factor Authentication" and details show.



Same thing with my phone I logged in at portal.office.com ... APPROVED single factor ... Ok maybe same IP?

That doesn't seem right or good considering I was in incognito...

So another test I logged into my Home computer in another city with a different public IP and was able to get into the account with single-factor as well ... What gives here? I want MFA to be required whenever a new login is attempted ... ESPECIALLY from a new device or a new IP.



The image above is a successful login from a different computer, different city, different IP and approved via single factor authentication.

 

[nlinecomputers]

It can take one hour for changes to go into effect.

 

[thecomputerguy]

Again just tried a totally different computer in a different city with a different IP and was allowed login via single-factor at portal.office.com

I don't understand.

After logging in I am able to access all data including web based Outlook ... then when I click the user at the top right and click "View Account" to verify that the user has an authenticator enrolled I am prompted for MFA ... Why can I get into OWA using Single-Factor?

 

[YeOldeStonecat]

See what I mean about security defaults not really being that good?
Conditional Access can be...100% solid, effective. Well, 99%...as something Microsoft does is likely to never be 100%...LOL. However..yeah, security defaults..it's fuzzy, it's...almost a step (small step) in the right direction, better than nothing at all...but if you want security on a tenant...use Conditional Access.

 

[thecomputerguy]

See what I mean about security defaults not really being that good?
Conditional Access can be...100% solid, effective. Well, 99%...as something Microsoft does is likely to never be 100%...LOL. However..yeah, security defaults..it's fuzzy, it's...almost a step (small step) in the right direction, better than nothing at all...but if you want security on a tenant...use Conditional Access.

This seems like a step backwards in MFA. With the legacy MFA I could just enable it and it would do exactly what I want ... require MFA as expected with new logins, new devices, incognito logins, new IP's ... etc...

So when they depreciate legacy MFA unless I move a client from Business standard to Business Premium they will be required to setup MFA a single time and then from that point on it's basically going to let anyone in via single-factor authentication as I am experiencing now?

This seems like a HUGE step backwards in security. For some of my clients that currently use 30 licenses of Business Standard this is what its going to be unless we upgrade all of them from $12.95 to $22.95?

So $300 a month to get what we previously had?