emailsecurityguy - Tumblr blog

[emailsecurityguy]

More of a Rant than a Post

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).

Kinda blows my mind that Google is letting this stuff through.

[emailsecurityguy]

Lizards and Phone Calls

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.

Verify. Always.

[emailsecurityguy]

A New Little Trick

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:

Yeah, they're actually trying to use the "trusted sender" paradigm to make you feel more at ease.

[emailsecurityguy]

What is up with Gmail?

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'd love to hear people's thoughts on this.

[emailsecurityguy]

One of My Favorite Metaphors

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.

Changeups are good. Good for baseball, good for Cybersecurity.

[emailsecurityguy]

A Friendly Reminder

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.

TL:DR - MFA tokens may be better than MFA pushes.

[emailsecurityguy]

Phishing Scams on the Rise?

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."

One of my favorite parts about working for a cybersecurity company is that I get messages like these, copy the URL, and feed them directly into our threat analyzing software. This basically renders that particular attack useless across my company's entire customer base - not that we wouldn't stop such horrible attempts anyway.

[emailsecurityguy]

The Parts of an Email

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.

Most email filtering systems will look across the entire body, any and all attachments, and headers to help determine if a message is malicious or benign. Until DMARC sees widespread adoption, there is no binary (true/false) way to determine if a message is "ok", so most email filtering systems will use a scoring system (typically 0-100) across multiple areas. For example, you can look at authentication data only and make a binary determination, or you can use authentication data as part of a holistic approach (I.E. if it failed SPF, we might still deliver it, but make it more likely to be flagged as an impostor).

[emailsecurityguy]

Don't Do This

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.

Basically, if your business process involves sending files via email, please think of a better way.

[emailsecurityguy]

Mail Flow Direction Matters

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

The next question, DLP, is a good consideration as well. Do you trust your users? ALL of them? Even the ones who are about to get their two week notice? What about the ones who just don't care about their job any more? If you trust your end users in all those scenarios, sure, don't care about DLP. If you don't trust even a few folks 100%, it might not be a bad idea to have a talk with your Legal/Compliance/Risk Management teams about the kind of data you want to protect from being exfiltrated.

[emailsecurityguy]

It Takes Two

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.

General troubleshooting should ALWAYS be performed. If you're trying to send a message, are other systems accepting your connections? If so, the fault is likely not your system.

[emailsecurityguy]

DMARC Reject, or "They're TELLING you to reject it."

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:dmarc_rua@emaildefense.proofpoint.com;ruf=mailto:dmarc_ruf@emaildefense.proofpoint.com; 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?

If your management gets grumpy about this, tell them that UPS told you to do it.

[emailsecurityguy]

General Best Practices: Solve Problems early

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 "robert.skinner@corp.com" and you accidentally call him by his nickname when you type: "rob.skinner@corp.com". 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.

One thing I remember from my first job was a coworker who used the phrase "garbage in/garbage out" - if your data is bad early in the pipeline, you're going to get bad data at the end of the pipeline.

[emailsecurityguy]

Password Protected Attachments and What They Have to Do With Physics Cats

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.

I'm curious to hear how your organization handles Password Protected Attachments.

[emailsecurityguy]

Only Tangentially Related to Email ...

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.

That's right, a threat actor can open a "new" account with your SSN and maybe mom's maiden name and get Experian to basically just change the email address (where a lot of two-factor stuff goes) on your account.

[emailsecurityguy]

TLS: What It Does, What It Doesn't Do

TLS. Transport Layer Security. When it comes to email, a lot of folks don't know what it does, and what it doesn't do. So, on to the basics:

TLS is a protocol that can encrypt a communications session after the session has already been established. It is a stateful protocol, meaning that it remembers things previously established (or stated) for a small window of time. When it comes to email, TLS will encrypt most of a message assuming that both server and client support it. Some things to know:

Assuming the receiving server supports TLS, it will offer it to a client after the initial handshake (essentially the HELO).

If the client can support TLS, it will list out the versions of the protocol along with the cypher strength it supports, and the server will pick the highest mutual version/strength. This is called opportunistic TLS, and is basically the server saying, "Hey, you wanna switch to a TLS session?" and the client (90+ percent of the time) saying, "oh, totally, here's what I can handle."

The client then picks a random number and encrypts it using the server's public key. The server, using its private key, should be the only thing that can decrypt that number. This will be the basis for the secure connection

Although your TLS certificate can match the DNS reverse lookup of your IP address, it's not necessary for the purposes of encryption. My opinion; don't require this. There are other ways to authenticate a server is who it says it is.

The subject line, envelope sender, and recipient of an email is never encrypted via TLS - don't ever put anything sensitive in the subject of an email. It's actually illegal under HIPAA to put one of the 18 generally accepted data points in the subject.

TLS does NOT encrypt data at rest, only data in transit.

If you set your TLS requirements beyond what the other side of an email session can handle, TLS will fail and the message may be transferred in the clear, so in a strange way it may be better to set your requirements low and just trust TLS to auto negotiate to the highest mutually available cypher and protocol version.

[emailsecurityguy]

You Are the Weakest Link.

Ok, disclaimer time; I work for the company that has made People-Centric Security their mantra.

That being said, people are the weakest link in your organization. I don't care how much you think your end users are savvy, well-trained, or able to not click on links, they are still your weakest link. Add to that the fact of phishing emails are still the number one attack vector for cybersecurity, in terms of volume of attacks, and you have a ripe conditions for your end users to click on something bad.

I'm gonna be a bit non-PC here; Every organization has one of those people who's just shy of retirement, in their 60's, they're fantastic at what they do, but they're not very computer savvy because the 80's was absolutely horrible about telling us how computers really worked (remember pop culture taught us that every computer was sentient, robots were common, and computers could control anything electronic even without a network interface).

Well, those people will click on stuff. Email about a package that won't be delivered? Oh, I'd better click on that. A PDF warning me that we're late on a payment and going to get sued? I'd better open that.

So how do we fix that?

Well, there's no one magic bullet to stop that. It needs to be a multi-tiered approach.

First off, end user training. Train them to look at the email address and confirm it matches messages they previously have received. Train them to stop and think before they click. Train them to reach out to IT if there is ANY question about a message's authenticity. Quite a few organizations offer it: Mimecast, Udemy, KnowBe4, Proofpoint to name a few. They typically offer more bells and whistles if you subscribe to their email filtering services as well (if they offer it).

Second, try and stop those messages at the perimeter. It's sad but true that email security, for the most part, is a reactive science/art. All of the big security companies still react to threat actors and threat campaigns. That being said, a number of things will help; warning tags on authentication failures. Heightened security scanning on a list of impersonation targets. A sanity check on any request from an email that asks for monetary changes.

Third, work with your security vendors and buy into any integrations they may have. If your email security vendor can integrate with your firewall to analyze incoming URLs real-time, do it. If you have a workstation monitoring vendor who can analyze clicked links, set that thang up.

Finally, the line between security and usability is often a thick, blurry line. Don't fall into the trap of letting the business side lower your security posture because "we have to click three extra times". All it takes is one bad click and you're the next Equifax ... and you're not in the position to survive what they did. They're one of three companies that do what they do. I'm not saying ignore business processes, I'm saying inform your end users that in the long run choosing complete ease-of-use over security is the wrong choice.