In today's episode, Frank covers email security from top to bottom. This includes what you need to do to prevent an email phishing attack, how to best train your employees, and what to do if you become a victim!
Complete the form to register for the "Cybersecurity for the Rest of Us" series. You’ll get an email reminder before each livestream, plus an email with a link to the recording in case you miss any of the live events.
All right. Today, we're going to talk about email threats. So all the good things that you've done. All your phishing prevention training, whatever you had in place. All those things kind of let you down, or more commonly, somebody in your organization did something.
But you detected a cyber attack somewhere, and it was some type of a breach. I'm going to focus today on email security solutions. In general, these type of attacks are more focused on financial extortion. These are not your typical ransomware or dropping malware into your environment.
It's all about the fake invoices. The getting you to disclose some sensitive information. It might include some proprietary information. But more often, it is financially motivated.
I'll start out by saying, one, that this is not very common, but it's more common than you would think. You may receive a call. And typically, it's going to go to a non-IT person. It'll be like the CFO or the COO. Somebody who's easily recognizable either through your website or maybe through a DNB type of entry.
You'll get a call that says, "It's special agent, whoever it is, from the local field office of the FBI." And they have information concerning a hack of your email account. Please, give them a call back. And it sounds exactly like spam. It's right up there with, "A warrant has been issued for your arrest. And the IRS has a claim against your social security number."
And it's unfortunate that they come off that way because these could be in fact totally legitimate. So if you get a message like that, don't instantly disregard it. Call the local field office at the main number. Don't call the number that the agent left.
You can verify their identity that way. If you are an Ntiva client, you can reach out through the service desk. They'll pass it over to somebody on my team. We have contacts at the local field offices in the DC Metro area Baltimore. We can verify them that way as well.
The thing that makes this kind of frustrating is they'll usually say, "We've detected some activity. We think you may have had a targeted attack," but they don't have a lot of information that they can provide. What's been happening. We've had these national security level incidents that have happened over the last 10-months. Let's go back to solar winds.
Well, the law enforcement community has been very actively involved with the technology community. And what's been happening is they've been investigating very specific things. They've seen other tangential events. Basically, it's kind of a CYA on both the technology and the law enforcement side.
They're telling you that, "We saw some activity. We saw something suspicious," but quite frankly, they don't have a lot to go on. And they rarely can share even dates except in a very high level. This happened a few months ago.
A lot of this goes back to not having the logs available. We talked about that two weeks ago in terms of what the retention period on logs and things are. If they have some specifics they can share like a date range or something, maybe a user account, and you've got a good logging back up. You've got a SIM solution running. You'll have access to that stuff.
You can maybe do your own forensics investigation. But if you get that call, it is entirely possible it's legitimate. It's worth following up on. If you completely ignore it, you'll probably have a federal agent show up at your organization's headquarters at some point.
So take that seriously. But recognize that your ability, your IT provider, if you're an Ntiva client, is going to be a little limited to maybe give you a lot of information and back up in a really thorough forensics investigation.
So just real briefly, you've heard me preach about not having MFA enabled on your Office 365 tenant. All I can tell you is that if you don't have MFA enabled on your O365, I'll say it again. Shame on you. It's not that big of an inconvenience to users, but it is a deterrent.
It is another hurdle that an attacker has to jump. It's not full proof. It can be circumvented. But at the end of the day, if somebody logs... tries to get into your system through a compromised password, and they're prompted with MFA, most of the time they're going to go on to find somebody else. They're always looking for the low-hanging fruit.
We have seen, and I've seen numbers put out for a variety of things that said when a hacker gets into your systems, they will typically be there for on average 83 days. Now, I don't know if that's really a great number or not.
Sometimes it's real quick attacks, but we do see lots and lots of lurkers. So compromised password, wherever it came from, not usually a password spray attack. Usually, it's compromised credentials of some kind. So [inaudible 00:06:36] probably goes back to a phishing attack.
They get into your accounts. They will typically set up a forwarding on some select mailboxes, right. It's going to be on the CFO, maybe somebody in accounts payable accounts receivable. I mean, these are fairly well-targeted type attacks. And a lot of times, this information's on your website, and certainly, they know who your CFO is.
Some organizations have contact us. You put your LinkedIn profile links up there. You've got all kinds of information. Generally speaking, less information is better in my opinion, but that's up to you. Going back to the LinkedIn scraping attack that happened a few months ago. 770 million records are gone.
They claim that it didn't take any private information, but it's a pretty easy way to figure out, "Hey, here's where you work. Here's your job title. Here's your email address." Right. That kind of stuff was all part of that attack.
So everybody is at risk based on that. If you had a LinkedIn profile, you can assume that people know where you're working, what your job title is. But they're going to get into those accounts. And right now, we're seeing some of these lurking attacks.
They come in. They set up a forward. So they're going to forward mail out of your O365, and it's going to be sent to another mailbox somewhere. They're setting up an account somewhere. Typically, at this point, the email platform is a Gmail, a Hotmail, and AOL accounts, stuff like that. And basically, they're looking for patterns.
Who's sending you invoices? Who were you sending invoices to? Once they've been in there for a little bit of time, they're going to take that information and now they're going to create a spoofed domain. So there are some really obvious things that you can do to spoof a domain. Multiple characters together, double M, double V, double I, J lowercase J's, L's. Subtle changes to those.
So if somebody domain has a W in it, replace it with two V's. At a glance into most users, it looks exactly the same. Or domain registration, it costs next to nothing.
The hackers are using up an organization. It's namecheap.com. I guess they have really low rates for registering domains because that's where I've seen a ton of these spoof domains get registered. They will then turn around and send an email from the spoofed domain.
It may be to your clients. It may be to you. It really depends on what the direction of the attack is going to be. But they've been lurking in there. They've seen what your invoice looks like. They know invoice numbers, [inaudible 00:09:49] amounts.
And, in some cases, they have the actual invoice because you attached it as a PDF. They'll turn around then and intercept it, maybe delete it from the real recipient and send that in. And in the email, they'll say, "Oh, and by the way, we've changed our banking information." And so, completely valid invoices, valid amounts expected. The timing, everything is perfect.
They're even going to go in there and probably copy a signature block. So it looks the same. If you have a disclaimer in the email, they'll try to capture all that stuff too. They're going to make it look as realistic as possible.
They're going to submit that along with fake banking information. If you don't have a good accounting practice that says, "They changed their banking information. And I'm going to verify it before I process it." Again, that's on you. Technology can't prevent that one.
But at that point, somebody turns around and wires the money to the wrong account. And the beauty of these types of things are, they're probably not going to be discovered for between really 45 and 60 days. So that invoice comes in, gets deleted from the real recipient. The hack goes on. The payment goes to the wrong place.
Whatever that timing is, think about how this generally works. You submit an invoice, typically has 30-day terms. 30 days comes and goes. Well, it takes a few days before maybe you're running your age day R report.
You go in and look and say, "Oh, this company, they forgot to pay us. They've been pretty good up to this point." Send an inquiry over. They say, "Oh no, we paid that invoice. Oh, well, okay. We're not seeing a record of it. Let me check."
You do a little bit more research. Another few days goes by. Before you know it, that money has been long gone, right. It's been transferred to the fake bank. It's gone to a couple of different places. You're not going to recover any of that money at that point. Now you've got some choices to make. What do you really do at that point?
So the first thing I tell people all the time, and this is actually part of our incident response plan. Step one is don't panic. So for the hitchhiker guide aficionados out there, right. Don't panic. This is important.
You need to react as quickly as you can. Even though it's not likely that you're going to do anything to recover the money, you need to [inaudible 00:12:31] you're aware of the incident. You need to be prompt and start doing some things. So number one is, get out your incident response plan. And if you don't have an incident response plan, you should have one.
It doesn't have to be overly sophisticated, but it should at least say, "I need to call the CFO. I need to call the CEO. I need to do whoever internally, externally."
Again, if you're an Ntiva client, "I'm going to notify Ntiva. I'm going to send in a ticket. I'm going to follow up with a phone call so that I get action on it right away because this is important." So at this point, you probably will have already figured out whose email account was responsible for the hack on your end.
So, number one, you want to get in there and say, "Let's change passwords. Let's make sure we had multifactor authentication enabled." Do those things as quickly as possible. Next step is to capture the logs. So if you were with me two weeks ago, I reminded everybody that the Microsoft licensing you have, for instance, directly determines what your log retention and your ability to respond to a forensics incident is.
So get in there. You want to get Azure AD logs on log-in information for the affected users. You want O365 information. What did that account touch? Run it for at least 90 days.
If you don't have a 90-day retention on things, you'll get what you get. But try to run it for 90 days and see what's in there. You're looking for foreign logins. Unrealistic logins, anything kind of out of the ordinary, but you want to do that as quickly as possible because those logs do expire and start overriding. You're only going to have part of the information.
Now, the other thing you need to do in order to actually trace emails and see if they're legitimate and stuff. If you're going to send them into us, into the service desk to look at, forwarding the email from your inbox is not going to give us the information we need to check. What you need to do, and you should do this regardless.
If you're using Outlook, file save as, and you're going to save the message that came to you as a EML or an MSG file format. It varies. Depends on the versions and things what it defaults to. But basically, every email that goes from that spoofed account, if it was a spoofed account or the suspected hacked account at the other company's side.
You want to export those and save those, preserve them. Related to that, and I'm not a lawyer, nor do I play one on TV. But I always say this. Look at enabling a litigation hold on the affected mailboxes because you don't know where this is going to go.
There might be a conversation with lawyers about who's liable for it. Who still knows who money. There's lots of things that come into play there. So go ahead and enable those litigation holds, export those mail messages, and then somebody can look at them.
So when you save the message as an MSG or an EML format, the texts will be able to go through those and look at the actual headers and say, "This message originated here."
And we can kind of track our way through. And what typically happens is we see a series of legitimate email messages, and then we see the series where it changes and becomes the spoofed email on one end or the other. That gives you a data point on, "Okay, we need to look at logs, definitely from this point." There's a lot of different things factor in there.
The reason I say you only have half of the logs is while you have the... I'm sorry, while you have half of the emails. You have the log files that show where email went back and forth, but you only have the stuff you received in terms of being able to track it.
So if somebody at the other company says, "No, you sent me an email here." You're looking at your logs and say, "No, it wasn't." That could be because somebody spoofed your domain at that point. So you won't necessarily have everything there.
You can ask the other company. "Could you send me that EML file?" More often than not, at that point, they're circling the wagons, and they're not going to share that with you. So don't be too surprised about that.
Again, this should be part of your incident response plan. But at this point, you probably want to notify the other party. And at this point, they probably know, but maybe not. It is a business decision on whether or not you're going to involve your insurance company if you have cyber insurance. Whether or not you're going to notify law enforcement.
Whether or not you're going to involve your legal counsel. All of these things come into play at that time. Depending on your line of business, and the industries that you serve, and who your customers are. You may have other notification requirements, and these should all be part of your incident response plan.
If you were a federal contractor, you probably have a notification requirement for a cyber incident. If you work within healthcare, right, HIPAA. You've got notification requirements. I'm not going to go through all of them but just think about all the different things that you might have to do and the people you might have to notify as part of that.
It should be on your incident response plan. By the way, most companies that want to be notified if they have it in your contract or in the whatever type of agreements, whatever you have with them. Typically, they're looking for some relatively quick notification.
Now that could be as short as 24 hours, or as long as 72 is typical for it. That does not have to be a detailed notification. That could be as simple as saying, "We think we've had some type of a data breach, or we think we've had some type of financial loss," whether it involves them or not just depends again on your contracts.
That initial notification doesn't need to be very detailed or specific, but they will expect a follow-up with additional details. "Was any of our data compromised," et cetera.
So that's sort of is the lay of the land on it. None of this happens very quickly. The back and forth and trying to forget the emails, investigate the headers, figure out what logs are in there. I mean, all of that is going to take a couple of days, at least probably.
And so you're going to basically be a few days in, and you're going to go, "Okay. Now, what do we do?"
The reason why I suggest that you at least talk to your insurance company early on, some insurance companies have very specific response plans that you must adhere to if you're going to file a claim.
So that's part of setting up litigation holds, exporting logs, and doing all that stuff as early as you can, because then your insurance company may require all of that before they even will consider a claim.
There are some insurance companies, by the way, that require that you do a third-party incident investigation, and it may have even be as far as saying you have to use one of the firms that they have on their shortlist of companies that they work with.
As a side note, I've noticed that a typical policy, they may have a $25,000 deductible or retention. And that company requires that you use one of their third-party incident responders. The fee to that incident responder is typically $25,000.
It's the same as the retention or deductible. So the other things you can consider and some of this you should be considering now. But more often than not, people don't look at it until after they've had some type of financial loss. Enforce MFA on every account. And I know some people complain, and they go, "It's a convenience, and it makes my job harder."
But in fact, MFA rarely comes into play day-to-day operation in the business, but it does help prevent the attackers from getting in. If you have the appropriate licensing, do it with a conditional access policy and not on a per-user basis. On a per-user basis, exceptions can be made.
Accidents can happen. If you do it with a conditional access policy, it's going to be enforced in all of your accounts. Something I think personally everybody should do right now. And this is... I know I've been talking more about the O365 side, but this would apply if you're in G Suite or any other kind of system as well. Disable external forwarding.
Now, this doesn't prevent somebody from receiving a message and saying, "I need to send this over to somebody at another company, a business partner, a subcontractor." Doesn't prevent forwarding of messages. It prevents automatic forwarding of messages.
That's both a data loss prevention as well as a good security rule. That's where email comes in, gets hit, gets deleted from the end-user, and gets... or the actual recipient and goes to the fake mailbox. I mean, there's all kind of different things going on in there. Different rules can be in play but disable that automatic forwarding. There's rarely a good reason to have it running.
And in most cases, the bad reasons outweigh the good. A SIM solution running in the background. That's going to give you a lot more audit capability and a lot more investigative capability if you've got a SIM running. There's all level of SIMs.
I won't even pretend to tell you how expensive or cheap or anything are. But go ahead and turn that on because that'll go a long way to helping you if you do have an incident. And by the way, they do help also prevent incidents because they set flags and things like that. It'll flag when it sees a user setting external forwarding and those kinds of things too.
Business email compromises driven when somebody does the classic, "I'm the CEO. Go buy $10,000 worth of gift cards at GameStop" because they spoofed the domain externally. You can add an email banner. It's done with transport rules, little thing on it that says, "Please be extra careful. This email originated outside the organization."
It's entirely up to you what it says. I know people hate them because if you get into an email conversation, they start showing up. And if both companies have it, every other email, and I got it. It looks a little ugly at times, but it's good prevention.
Having a standardized signature block is more about brand identity for most people, but it's also a good security measure. If every email from every person in your company looks pretty much the same, that's a security measure.
Somebody gets something, and it doesn't have your signature block the same way or the way that they're used to seeing it. It's another visual clue that maybe that won't happen. If you have an incident, maybe it was a hack. You didn't lose any money. It was a significant phish. Somebody gave anything up.
Even if you don't feel like you need to notify law enforcement and get everybody involved, file a complaint through ic3.gov. That is the easiest way to file a complaint with the FBI. They may or may not even reach out to you if there was no loss involved, but they do like to collect that information for metrics.
They like to know what kind of attacks are going on. And they like to see the patterns because that's good advanced threat intelligence in general. After it happens, don't hide it. Use it as a teaching moment to all of your employees. Ideally, the person that was hacked or did something silly and gave away some money, they maybe could get together at your own brown bag. And say, "I screwed up. This is how I did it."
It will be a much more meaningful lesson for all of your employees. And I mentioned it earlier. Throughout this process, if you have in-house legal counsel, or you have somebody on retainer that you can reach out to. It's up to you how you want to approach that.
I don't get into the liability issues and all those kinds of things. I try to steer clear of it as a matter of fact. But get them involved and at least make them aware of what's going on because what might start out as a fairly benign amicable discussion about, "Oh yeah, we made a mistake, it was an email attachment, blah, blah," back and forth could turn into litigation later on. So make sure that that person isn't completely surprised two months from now or anything like that.
So we are coming up at the end of our 30 minutes.
Okay, thanks. And if you have specific questions, feel free to reach out. You can send them to me at email@example.com. They'll come straight to me. If you're an Ntiva customer, feel free to run anything you have.
If you have questions, you can run that through the service desk. Just send in a support ticket. If you have an incident, please get out your incident response plan and call us right away, and we'll attempt to go from there.
Watch the COVID issues. Watch the malware issues and phishing attempts. Every piece of sensitive data is subject to attack.
By the way, if you have a web-enabled baby monitor, Mandiant discovered a significant flaw, affects 83 million devices. So your baby monitors are subject to monitoring, both audio and video.
Check with your manufacturer and see if you're affected. But that's how bad things are these days. So it is what it is.
We're at 12:30. Thanks for joining us. We'll see you again in a couple of weeks. And if anybody has any topics you'd like us to specifically cover, feel free to suggest them at that same email address. Thanks and have a great day.
Ntiva’s Frank Smith hosts the Cybersecurity for the Rest of Us livestream every other Thursday from 12:00 to 12:30pm ET. These live events, presented by the Ntiva team of cybersecurity experts, are sharply focused, easily digestible, and cover topics surrounding cyber security in today's modern workplace. We take questions from the audience and share what's working for us and others in the industry.