As a cybersecurity analyst, we often look at phishing or spear phishing emails, and we wonder ourselves
how somebody could fall for it.
As a security in the field, you have to remember that you're properly trained and you're constantly
looking at these little hints or clues that identify it as a phishing or spear phishing email.
But what happens when that email is more than just a phishing or spear phishing email?
Maybe it's spoofed and it's coming from what looks to be a legitimate user or legitimate domain.
That's where email analysis really comes into play.
And you, as a cybersecurity analyst, need to be able to identify very quickly.
Is this a legitimate source for the email?
Did it properly come into play and into our environment from a legitimate source?
Email analysis is really one of those things that you have to take for heart and understand the proper
clues and the technology to utilize in order to understand if that email is truly valid, coming from
a legitimate Source.
In this episode, we're going to go over email analysis.
We're also going to talk a little bit about the frameworks associated with how to secure our systems
and the technology that we can utilize, both from a protocol standpoint as well as some of the other
systems that we can use to ensure that somebody that's trying to pull off a spoofing email attack against
our systems isn't successful.
For Cisa exam, you need to understand these technologies, these protocols and how they interact with
our different systems.
Email analysis is more than just understanding if the email is coming from a legitimate source.
We need to be able to analyze the content of the email itself.
Does it have malicious links embedded in it?
Are there attachments that could provide some unfortunate compromises to people that download them and
click on them?
It's not often that we don't see a piece of email with an associated invoice, or a link attached to
it, that is actually leading to a piece of malware.
We need to provide to our organization a clear cut pathway to stop these types of attachments and links
from getting through our systems.
We can also do what's called metadata analysis.
This is where we look at the actual data that's hidden within the email body or the email contacts to
find out where did the data really come from.
We can track the different routers and the source and destination codes.
We can track the legitimate information that's inside the email because it cannot be changed.
It cannot be spoofed.
We can look at the different links within the email, and we can look at the behavior that the email
has when it's going through our system.
All of these forms of analysis that go through our systems provide us a clear direction of whether the
email is legitimate or if it's coming from a malicious actor.
Within the email, there's something called the header.
The header is the portion of the messages that contains details about the actual sender of the email,
the route taken, and who it's going to.
Analysts can use this email to detect whether an email is spoofed or suspicious in nature, and we can
kind of derive from that information if that email has a legitimate purpose on our network.
You can see here that we provided a legitimate header information, and that it shows us that the information
is actually going to a specific user.
If you pay attention, you can see that it goes to past the yahoo.com to yahoo.com dot pH.
This means the recipient of the email isn't an actual user and is most likely spoofed.
It's not often that we don't see someone trying to pose as somebody they're not.
This is where impersonation comes into play.
They spoof the address that the email came from in order to make the victim feel like we are a position
of authority, a close relative, or even a friend, and impersonation is a major form or factor that
can provide the gateway from a legitimate email passing through our security systems, or a phishing
email passing through our systems.
This plays a major role in email security.
There is something called Sender Policy Framework, or SPF.
This works by allowing domain owners to publish their DNS records that specify which email servers are
authorized to send emails on behalf of their domain.
I want you to picture this sort of like a phone book.
I receive a phone call from somebody and that somebody is claiming to be my son.
Obviously, it sounds like my son, because of deepfakes and all this other technology that's out there,
but the phone number just doesn't look right.
I can go through and actually go, hey, who are you calling?
Oh, I'm on my cell phone.
Well, obviously you're not on your cell phone because my caller ID identifies that that phone number
isn't legitimate.
Now, the first thing that comes to your mind is, wait a second.
What if they're spoofing my phone number?
Well, we understand that, but that's where the Sender Sender Policy framework comes into play.
Unlike a phone system, we can actually go back to the DNS and identify is this a legitimate domain
that they sent the email from?
We.
This provides us enhanced email delivery because we know that the domain that they sent it from is legitimate
in nature.
And we can have our systems to identify those legitimate servers as part of our inward ingress into
our system, thereby allowing that email to process more smoothly.
We can also do spoofing protection through this.
If someone's claiming to have a domain such as, I don't know, yahoo.com, but it doesn't come from
a legitimate server, then we can identify that as a spoofing email and protect ourselves from it.
This reduces fraud and increases trust from that server, as we've identified the DNS associated specifically
with that email server.
Domainkeys identified mail, or DKIM, is another feature.
This generates a pair of keys, much like a public private key that we see in encryption, where the
organization's public key is published to the DNS records for later querying and in use by the recipient
when sending a message to Kim.
The sender includes a special signature header containing the hash of the email header, thereby stopping
the or providing integrity for that email.
A hash or a portion of the body and the details about the hash function can then be used to verify the
email came from a legitimate user.
Just like probit private encryption.
We can then see the publisher or the sender of the email, because they've signed the email and provided
the hash value of the content.
This stops man in the middle, attacks.
It verifies the signature of the sender and provides us a true trust determination through identification
of legitimate user, thereby stopping spoofing emails from crossing through our systems.
However, it should be warned that while it does verify the sender information, that doesn't mean that
the sender may have put or implemented spoofing or malware within the email, it only verifies that
the information was sent from a specific server, not that the email doesn't have, uh, malware embedded
within it.
Finally, we have something called domain based message Authentication, Reporting and Conformance,
or dMarc.
That's a mouthful, but this email authentication protocol is designed to empower email domain owners
and prevent spoofing and mitigate spam originating from their domain.
This is done through a series of technology, but provides spoofing prevention DNS record.
Cross examination and cross reference.
It can also be manually queried to ensure that the emails are actually coming from the legitimate server
in which it was supposed to originate on.
This, again, is just one more message protocol that we can utilize to ensure that our emails are safe.
It's not uncommon within our normal emails to see embedded links, whether it's a click here box or
a direct email link.
It doesn't matter what it is, but we see embedded links scouring our different emails from both legitimate
users as well as malicious users in certain contexts.
This isn't always a good thing.
You can see on our example here where we have a legitimate, uh, link or an embedded link within our
system, but it's providing an illegitimate or spoofing link.
If the user were to click on it, they would end up@malware.com or a malware site.
This provides an embedded link or a way for malicious users to provide a quick link for users to utilize
that could potentially lead to an unwanted or unauthorized Authorized website.
This is a major problem with an email today, and we should provide some policies or procedures to ensure
that our users aren't clicking on them.
One of the surefire ways is training, and with training, we can identify and say, hey, don't click
on the links, identify where the link is taking you first, and if it doesn't add up, don't click
on it.
If you don't recognize the user, don't click on it.
A lot of systems in place for many organizations today don't allow embedded links, and if you provide
an embedded link, it tells you exactly what the link is so you don't even have to hover your mouse
over it.
That provides us an additional security layer within our email security protocols.
Within this episode, we covered our email analysis.
We also covered how to look for headers and how headers can be utilized to identify spoofing or malicious
emails.
We covered impersonation and how users or senders aren't always who they say they are.
We've identified different frameworks and protocols that we can utilize to more safeguard our systems
and security within our email program to ensure that authenticity of the email sender as well as the
domains that are supposedly being sent from.
We also talked about embedded links to where we can ensure that our users are only clicking on links
that they know where it's going to, by ensuring that we don't allow the short fuse links in, and we
only provide the long link that actually proves they're going to a safe place.
We also provide training to ensure, on top of those embedded links that users aren't clicking on malicious
software.
Throughout this episode, we've talked about all these different things, but what I really want you
to get out of this is that for Cisa plus, you need to understand the common sense protocols that come
with not only embedded links, but also through domain based authentication, reporting and conformance,
or that dMarc protocol.
The DKIM or Domainkeys identified mail, as well as Sender Policy Framework or SPF.
These protocols you should expect to see on your Cisa plus exam, make sure that you understand the
acronyms associated with them and how that technology is pulled off.
If you can do that, you should be good for those scenario based questions within your Cisa exam.