SMTP Sending and depreciated app passwords.

[thecomputerguy]

I have a client who uses Applied Epic (insurance software).

They were running raw for awhile because they weren't my client until a few months ago so they were running no conditional access, and had security defaults disabled.

So, as of upgrading all of their accounts to Business Premium accounts and applying conditional access policies and tightening up the email system they can no longer email out of Applied Epic because they were previously running app passwords and manual SMTP settings to make it work.

They have 10-15 accounts that email out of Epic.

So is this a SMTP2GO angle?

Like I said they have 10-15 accounts so maintaining that structure where everyone uses their own email account to send out of Epic is going to be a nightmare to maintain.

With that said is this an SMTP2GO angle with a globally used no-reply@contoso.com angle for the manual server entry into Epic?

@YeOldeStonecat
@Sky-Knight

 

[YeOldeStonecat]

Yup last winter when Microsoft was peeling out app passwords, I did the same with a client of mine that uses Applied Systems...I flipped them over to SMTP2GO.

 

[Sky-Knight]

Yep, SMTP2GO is your answer, otherwise you may as well not have MFA.

 

[thecomputerguy]

Yup last winter when Microsoft was peeling out app passwords, I did the same with a client of mine that uses Applied Systems...I flipped them over to SMTP2GO.

Yep, SMTP2GO is your answer, otherwise you may as well not have MFA.

That's what I thought too ... is standard practice just to use a no-reply@contoso.com and deploy that globally right? Setting up individual users sounds like nightmare fuel.

Also, I've always wondered... I've used SMTP2GO before mainly to send scans from MFP's and the setup seemed pretty easy at the time, but I haven't done it in awhile.

So setup SMTP2GO account, add sender domain and then add required DNS records to verify SMTP2GO to send as the Domain. Then setup an account like no-reply@contoso.com then use that with the provided SMTP settings from SMTP2GO. Simple.

BUT

My question is, what is in place to prevent a bad actor from somehow gaining access to the credentials for no-reply@contoso.com and then using those SMTP credentials... just as I am to send mail? SMTP2GO obviously doesn't use 2FA and essentially functions as an SMTP server using an app password. A complex app password yes but still, it's just a password.

IP Authentication appears to just allow SMTP2GO to send from the Domain without using a username or password. per: https://support.smtp2go.com/hc/en-gb/articles/21149933711513-IP-Authentication

What is stopping me for example, if I was being malicious and somehow got ahold of the password of an SMTP2GO email address and just using it freely?

 

[YeOldeStonecat]

I'm trying to think of "Why I didn't use CA to just not require MFA from the range of IPs from Applied"....I know there was a reason I didn't, I think because Applied was going to keep going through some changes on their end for a while. Just went through emails with the guy I worked with at Applied (last name of Mooney)...must have been info he passed over the phone with me. Anyways...there's another option....CA policy. But I stuck with SMTP2Go for some reason.

Client was already using SMTP2Go for their MFP and already had the DNS records setup 'n stuff but I made another account for Applied so all users were using that same account.

Valid point about "What if those credentials were obtained?"....but it's highly unlikely. Only 1x person went around their office setting that up, the password was pretty crazy, not one that would be revealed in some phishing campaign.

 

[Sky-Knight]

You can use CA to bypass the MFA requirement from trusted addresses, but that doesn't grant portability. If you have an app on a laptop that moves around then what? We do have Entra ID Private access now...

SMTP2GO has some baggage to deal with as well to fully implement SPF and DKIM, ensure DMARC is happy. But once all that is set, it's fairly straight forward.

And there is NOTHING preventing a bad actor from using the single factor auth to spam things via SMTP2GO in your name, that is rather the point. But if that happens, it's SMTP2GO that gets black listed, not your M365 tenant!

The only real fix is to replace the app with one that has its brain screwed in and uses modern API access methods.

 

[Markverhyden]

Never heard of Applied Epic but after poking around they look like a pretty large outfit. The issue sounds very similar to one I went through back in Jan/Feb of this year with a trucking company customer. Their LoB app had been using it's own SMTP engine for sending emails from within the portal of the company's M365 Exchange. MS has forced OAuth2 on everything/everyone so that's what needs to get setup. Our customer's vendor had approached us about this so had some very specific steps to follow. I'd start by bring this up with Applied Epic. Link below gives you an idea of what's going on these days.

Authenticate an IMAP, POP or SMTP connection using OAuth

Learn how to use OAuth authentication with your IMAP, POP, and SMTP applications.

learn.microsoft.com

 

[YeOldeStonecat]

You can use CA to bypass the MFA requirement from trusted addresses, but that doesn't grant portability. If you have an app on a laptop that moves around then what? We do have Entra ID Private access now...

Applied Epic is hosted in Applied data centers, RDP to it

 

[britechguy]

Valid point about "What if those credentials were obtained?"....but it's highly unlikely.

Precisely. Not to mention there needs to be a motive for even trying to obtain them. Most often, there just isn't.

 

[Sky-Knight]

SMTP access credentials are sniffed via AI, they will be obtained it's just a matter of when. The assumption that any amount of effort is expended to get these tokens is irrational, ignorant, and indicative of a fundamental lack of understanding of the reality we lived in five years ago, much less the one we live in today.

It like every other risk is locked behind a single gateway to doom... And end user somewhere clicking on the wrong thing in an email.

 

[britechguy]

The assumption that any amount of effort is expended to get these tokens is irrational, ignorant, and indicative of a fundamental lack of understanding of the reality we lived in five years ago, much less the one we live in today.

And, yet, we just don't see this happening with any frequency. You love the edgiest of edge cases, I look at "what's actually happening and what actually happened."

An occasional security breach of any type is inevitable in the world of computing. Not everything needs "maximal protection," particularly when damage risk is low if a compromise occurs.

It is you, not I, who insist that risks are always incredibly high for everything and maximal security is always necessary. In reality, it is not, and is very often counterproductive in practice.

 

[Sky-Knight]

And, yet, we just don't see this happening with any frequency. You love the edgiest of edge cases, I look at "what's actually happening and what actually happened."

An occasional security breach of any type is inevitable in the world of computing. Not everything needs "maximal protection," particularly when damage risk is low if a compromise occurs.

It is you, not I, who insist that risks are always incredibly high for everything and maximal security is always necessary. In reality, it is not, and is very often counterproductive in practice.

I DO see it happening, EVERY SINGLE DAY.

Your "we" is the irrelevant part here. Every other phone call I have is yet another insurance company refusing pay out because of this breach or that, and specifically surrounding email.

The tiniest of SMBs are floating by right now because the juice isn't worth the squeeze, but the ease of attack is improving while defenses remain expensive and difficult. We're a year away from doomsday for the market segment you live in, tops.

I'm DONE watching people go bankrupt.

 

[britechguy]

I'm DONE watching people go bankrupt.

When I see my first one, I'll let you know. I'm not holding my breath and I really don't know how you're seeing this en masse.

But I really do need to resolve to stop having this back and forth with you, because it's abundantly clear that you do insist on using "Fort Knox" at all times whether it's necessary, or not. If that's your security blanket (no pun intended) then, by all means, go for it. Just know that most of the world isn't doing this when this does not need to be done and they make very careful determinations regarding when it does need to be done. There are different levels of threat, and different levels of damage for different kinds of breaches. All of that matters, and ease of setup and maintenance for "non mission critical" areas does not get, nor warrant, the same treatment as those that are.

Building a fortress when a chicken wire fence will do makes no sense, at all.

I've yet to see a single one of your "the sky is falling" predictions be true in the world I observe directly, and indirectly via venues such as this one, either. Yet you keep making them and there's no widespread evidence to support them.

 

[Sky-Knight]

@britechguy The real problem is your idea of Fort Knox is barely a wire fence.

Fort Knox is a fully deployed E5 security solution with a manned SOC watching the environment.

Configuring M365 to consistently enforce MFA barely qualifies as a dead bolt on the front door.