Nerdy Email Tech Info

Having run into some struggles lately while working with clients, I wanted to offer some advice for anyone working on a major or complex IT implementation.

Understand the Project Scope. Before your first meeting, make sure you have a clear understanding of what the project is all about. Review any project charters, statements of work (SOWs), project plans, or initial proposals. Know the key objectives, deliverables, and timelines. Stupid Personal Anecdote Time (SPAT): Last year at some point I was implementing a complete re-haul of a major company's email security. On the first call the primary technical contact was the only one from the client side who showed up, and he had no idea what was happening on the project. We ended up cancelling the first call after 5 of the scheduled 60 minutes, and we didn't have our next call with the appropriate resources until 2 weeks later. It turns out his CISO had received the initial scheduling/scoping email and forwarded it to him with no instructions.

Internal Stakeholder Alignment Identify the key stakeholders on your side of the business, I.E. who will be involved. This includes users, department heads, and anyone who will be impacted by the new system or process. Ensure they are aware of the project and their role in it. SPAT: Having been on multiple projects where weeks of time are wasted due to customer-uttered lines like "Oh, we'll have to involve Network Security and they need at least 2 weeks lead time", I strongly recommend the "if you're not sure, ask" approach.

MX records are DNS records that tell email systems how to route email for a given domain. When a sending server needs to deliver an email, it will look up the MX record of any/all of the recipients. Public DNS will return an IP address or A record of the destination server. The sending server will then attempt a connection to the returned IP address.

Things an MX record does: Tell a sending server how to deliver mail for a given domain

Things an MX record does not do: Limit email connections for a given domain to a specific IP address or FQDN

Affect your outbound mail in any way.

FAQ: Is there a way to only route certain email addresses in my domain to a specific server and some to other servers? No. MX records are an all-or-nothing deal. Any subsequent splitting of traffic would have to be done after the MX delivery

Do my org's MX records have anything to do with our outbound traffic? No, unless you have an MX entry in your SPF record (which is typically not recommended)

So I wanted to share a screenshot of my freemail Gmail account, and you'll perhaps see why I've given up on it and now use my Google Workspace account where I can put a 3rd party mail filter in place before delivery

Every single one of those are phishing emails. That's the last 36 hours. Even if I didn't have a 3rd party mail filter, in this particular case I could defeat the majority of those with just a few rules:

Block any email that has my last name in all caps

Block any email that has a partial local portion of my address

And the majority of those messages could be stopped with just that. I've opened most of those links in an isolated browser and my company's products blocked all but one (I submitted that one as a false positive).

My company loves acronyms. So much that we have an internal page with what most of our acronyms mean. Well, we didn't invent this one, but there's a new one going around and I want to talk about it, frankly, because it's pop-u-lar.

TOAD. Telephone Oriented Attack Delivery. While the initial threat may come in via email or SMS or drive-by website, the next step in that threat is to get you to call a phone number. I get these pretty often on my phone, looking something like this:

First off, notice the address at the top. It's a good bet that a legitimate business will not misspell a domain or account name. Second, PayPal pretty much only has you logging into PayPal.com. Third, and the biggest takeaway here, if you ever feel like a message similar to the one above is legitimate, DO NOT click on the link. Manually search for the company name in Google, and go to that website and sign in.

What happens once you call is a similar story too; most of the time you reach some sort of automated call center where they try to either push a "helpdesk" program to your phone or computer or try to get bank account information from you directly.

The bottom line is this, do not trust messages that talk about your account being disabled or money you've spent when you know you haven't.

It makes me wonder why they took so long to start to do this kind of thing, at least on the "throw spaghetti against the wall and see what sticks" method of blasting out millions of crudely crafted phishing emails and seeing what comes back.

But yeah, check this one out:

For anyone who's had a Gmail account for more than a year, I'm sure you've recently noticed the massive influx of fake "Ace Hardware"/"T-Mobile"/"Fill-Out-This-Survey-and-Win-Something" phishing messages.

You're not alone. Between going to bed last night and this morning, I got 5 emails along those lines:

Two purporting to be from T-Mobile

One saying I had won an iPhone 14

Two purporting to be from Ace Hardware saying I could fill out a survey and win a golf cart or generator

Here's a sample of one of the Ace Hardware ones (and I opened this in one of my company's products, a sandbox isolated browser)

Notice the attempts to legitimize and/or get you to click: 

Comments with a number of reactions below them

You can fill out your own comments

The ACE logo in the corner

A promise of free stuff

A sense of urgency (giveaway expires today!)

Some of the telltale signs in the actual email that it’s phishing:

The use of a portion of your email address or your capitalized last name only, often with no spaces or punctuation:

The email body has a minimal amount of text and is all embedded images:

The lack of TLS:

The spaghetti message header “from” field:

It’s gotten so bad that I’ve more or less given up on my Gmail account. I’ve been forwarding certain messages to a different domain where I have one of my employer’s products in front of it filtering email.

I don’t really have a good solution for those of you who can’t just dump your Gmail account, but a few things to note:

This seems to be focused on Google more than other “freemail” domains like Yahoo, Hotmail, or Protonmail

The older your email account is, the more likely you are to get this garbage

Google somehow seems powerless to stop it

Use common sense. If a giveaway seems to good to be true, it is. Publisher’s Clearing House will not let you know via email if you win something big. No companies give away anything worth more than a few bucks from an online survey.

I've never made it a secret that I really like baseball. It's my favorite sport by far, to watch, to soak in, even to occasionally dabble in (in the form of embarrassing myself at the batting cages).

I may not be that good at it, but I like to think I really, really understand it, especially that pitcher on the mound whose job it is to make sure runs don't score against his team. In modern times there's been so much emphasis on speed, how fast that guy can throw, etc, that I feel like the changeup is a lost art.

You see, professional hitters are really, really good at timing things. If they know a 102 MPH fastball is coming there's a good chance they can absolutely mash it. Tater city. But the changeup? Take a guy in his prime like Jacob DeGrom of 2018 and see how many strikeouts he had on his changeup. Hitters didn't just swing and miss, they looked foolish swinging so far ahead of it that letting go of the bat and looking like a flailing little leaguer was not uncommon.

Well ... your end users are the same thing. They're the most dangerous when things don't change. Sure, you have that warning message telling them that the email is from outside your organization, but guess what? Their brain has seen it hundreds of times, maybe thousands. Want to do everyone a little favor? Change it up. Maybe just the font. Maybe the color. Change it every few weeks, so that "Warning: This email came from outside our organization, please ensure you recognize the sender and open with caution." doesn't become something they ignore because it's always there, it becomes something that makes them glance at the from and sender fields.

A few very basic security concepts, I just wanted to remind everyone that TWO FACTOR AUTHENTICATION ON THE SAME DEVICE IS TECHNICALLY NOT TWO FACTOR

What does this mean? It means if you access something related to work on your phone, and the 2FA is on your phone, there is no second factor. If your phone got compromised, everything the threat actor needs is right there.

So shifting a bit, it has come to light that the Uber hack was multi-stage and the first stage was bombarding the target with MFA push requests. This worked because the target was essentially worn down until they clicked "Accept" and allowed the attacker in.

At this point, since they were on Uber's general network they used an internal communication channel to impersonate helpdesk.

I've been on Gmail since the beginning, I got one of the beta invites and my email address has not changed. Lately, I've been seeing a massive increase in emails with content like the following get through:

So aside from the atrocious grammar, and the fact that Ace Hardware doesn't do giveaways like this, you can also tell it's fake from the address section:

Phishing emails tend to fall under 2 different categories with 2 sub types. You have the scope; a message will either be targeted at a specific person or at a wide array of people (often referred to a spearphishing or netphishing). And then you have the effort put in by the threat actor, you have extremely well crafted (which the above is not), and "throw crap together really fast and blast it out to as many people as possible."

Emails are so much more complex than just the subject and body you (typically) see in your client, be it Mac Mail, Gmail, or Outlook. Some of you may have actually downloaded an email or clicked the "view original" button in Gmail, or looked at message properties and noticed that there is a ton of technobabble in there. That technobabble is called "headers".

Email headers are not unlike the postmark on an actual postal mail; where the postmark will validate when/where a letter passed as part of sorting, email headers will list out all sorts of things; what servers the email passed through, if it was authenticated using SPF/DKIM/DMARC, as well as custom metadata like antivirus versions or DLP checks.

Once upon a time, email was fresh and new and it was for text only. That makes sense, because back when it was invented (in the early days of of ARPANET) you didn't really have much graphics for computers; heck, my beloved Commodore 64 hadn't even come out yet.

Computers got faster and better and graphics started to see a lot more use, and people realized they could send files attached to emails. Well, people being people discovered "I can send cute pictures of cats to my friends!" and it was all downhill from there.

That's all a very long way of saying, "don't use email as a file transfer system. It was never meant to be one." Of course send one-off files; a PDF related to your D&D game, cat pictures, a resume, whatever. Just don't compress hundreds of log files into a zip and send it via email. First off modern email filters need to expand compressed files to analyze them, and file compression can be a really, really processor intensive task. Second, overhead on attachments can be big, especially if you're encrypting things.

So first off, I'll say that the generally accepted thought is that email filtering is the responsibility of the recipient. That being said, inbound vs. outbound filtering is a good conversation to have. Some questions to ask yourself:

Do we need to filter outbound email?

Do we need to worry about Data Loss Protection (DLP)

So for the first question, there are some considerations depending on what kind of organization you are. Higher Education? Heck yes you need to filter outbound. High School and College students can and will do dumb things. Some of them don't give a darn about their account and might allow it to be hacked/compromised. Some of them will "play around" and send out a mass mailing for some kind of prank. You don't want your domain to end up on Someone Else's Block List, so filtering for outbound is not a bad idea in general

Having been an email administrator for years, I've noticed that there is a dangerous assumption;

If an email does not get delivered, it is clearly the fault of my company's email system.

Think of an email connection like a phone call; you have to have someone making the call, and you have to have someone receiving the call. Remember from a previous post, when a server wants to deliver an email it'll typically look up the recipient domain's MX record and attempt to open an SMTP connection there.

Just like that phone call metaphor, if the other side doesn't answer, the message won't get delivered.

We've talked about DMARC records here before, but a quick summary:

DMARC is a way to use either SPF or DKIM to validate the authentication of an email

DMARC are TXT records in DNS, so they are on a per-domain basis

In a DMARC record you can not only ask for feedback to a specific email address, but you can specify what the recipient should do.

So let's take a sample DMARC record, from an organization that is frequently spoofed, UPS. Their DMARC record has this:

The big thing there is that they have p=reject:

v=DMARC1; p=reject; rua=mailto:[email protected];ruf=mailto:[email protected]; fo=1

This means that UPS is telling anyone who receives email that purports to be from them to reject that message if it doesn't comply with DMARC authentication. Yet, I've worked with plenty of organizations that still are not rejecting emails from domains that have p=reject because "management doesn't want to block anything that could be legitimate."

I get that you could have emails sent out on behalf of UPS that you don't want to block, maybe their marketing or sales team is using Constant Contact or Mail Chimp to blast out stuff, but the people who hold the keys to their DNS system are TELLING YOU to reject those messages, why would you not honor that request?

One of the biggest challenges of IT is linking separate systems together, E.G. a directory server (LDAP/AD/X.500) that contains a massive database of user objects needs to be updated from multiple SQL databases. Email systems will then look up that directory server to get email address information. Maybe workstations will login using that directory.

We see this all the time in the email world. As I mentioned in a previous post, sending an email to someone outside your organization can go through many servers. It could go from your workstation to your corporation's email server, to an outbound filtering server, to a different organization's inbound filtering server, to their email server, and finally to the Outlook client of the recipient.

Well, say you send an email and typo the email address? You meant to send to "[email protected]" and you accidentally call him by his nickname when you type: "[email protected]". That message will not actually be delivered because he doesn't actually have the alias for his nickname, but where will that failure occur? It should take place after your org's outbound filter goes to hand it off to corp.com's inbound filter.

Another way of putting it; solve problems as far up the pipeline as possible. It doesn't make sense to check for valid recipients by the time the message has already made it through the inbound filter, because that's processing time and network connections and memory that simply don't need to be used. If you're going to globally block a domain, do it at the furthest point upstream you control.

Most of us have had to deal with password protected attachments in email before, and on the surface they seem like a great idea; "Hey, let's slap some mild encryption on this file so that only someone who knows the password can view the file!" This is what I call Schrodinger’s Attachment. Just like the famous cat-in-a-box, where we can’t tell if the cat is dead or alive until we observe it, with the password protected attachment we can’t tell if the “payload” is malicious or not until we can open the attachment and … we can’t open the attachment (because it has a password on it)

So let’s talk about some things here:

Why do people password protect files

What do you gain from password protecting files

What do you lose from password protecting files

What other options are available?

First off, why do people password protect files? Once upon a time, email was pretty much not encrypted. At all. In fact, until the mid 90’s a lot of email was transferred using a “store and forward” mechanism which meant that any number of intermediate servers could be “holding” your email until the final destination accepted delivery. This meant that anyone with admin access could view that attachment. Password protecting the attachment was theoretically a way to ensure only the intended recipient could open and view the attachment. There were problems with that; how you get them the password? If you’re sending the password over the same channel (email), you’re no more secure than sending the attachment in the clear, even if it’s on a different email or message thread. If that password is not changed regularly (I.E. you set a static password and use the same one reoccurring), you’re really not much more secure than if you don’t use a password. With modern email systems, near 100% of messages are being transferred using TLS, meaning the email is encrypted in transit, and because Microsoft and Google also offer encrypted data at rest, all your messages are already encrypted at rest. You’re not gaining that much from password protecting attachments in modern times

So next up, what do you gain from password protecting attachments? Well, assuming the password is secure (unique, complex, changes regularly, etc) you ensure that no one but the holder(s) of the password can access the file. That’s pretty much the only pro of using a password to protect a file, even if theoretically it is a big pro.

What do you lose from password protecting files? Well, from both a security and DLP standpoint you lose the ability to see what’s in that file. For outbound emails this means you are theoretically opening a data exfiltration hole; you’re making it so a rogue or disgruntled employee could send sensitive data to an external email address by password protecting a file. For inbound emails this means those attachments can’t be scanned. They could be hiding macro viruses. They could be hiding malicious URLs. You are essentially making it so that the end user and only the end user has the ability to perform security scans on the attachment.

So what options are available? (keep in mind a lot of these are not mutually exclusive)

As far as delivery is concerned, block and allow. We can block password protected files, or we can allow them. In most email filtering systems this is available both globally and on a per-sender and/or per-recipient basis. This allows us to get pretty granular: Examples would include “Block password protected attachments for all users, unless the sender email ends with pwc.com and the recipient is in the accounting group.” Or “Allow password protected attachments for all users but only if the sender is not gmail.com or yahoo.com”

Most email security systems also allow additional options of modifying the incoming message; I.E. We could drop an annotation into the body with red and yellow colors that warn the recipient to 100% ensure they know what they're doing when they open a file that couldn't be scanned by automated systems.

Giving us an example of stunningly bad security practices, Krebs pointed this out today about Experian ... https://krebsonsecurity.com/2022/07/experian-you-have-some-explaining-to-do/ The TL:DR of the article is that by opening a new account with Experien using an existing SSN and some other moderately-easy-to-get PII, you can essentially change the email address on the existing account with pretty much no oversight.