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
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 cys A 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 spooked.
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 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 message 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 smooth 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
pay attention, you can see that it goes to pass 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 impersonation is 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's
somebody is claiming to be my son.
Obviously,
it sounds like my son because of deepfakes
and all these other technologies 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 Senator
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
with us,
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 in word
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,
domain keys, 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 query and in use by the recipient.
When sending a message to TK
I,
the center 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 propi
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,
identification
of legitimate user,
thereby stopping spoofing emails from crossing through our systems.
However, it should be warned that while it does verify the center information,
that doesn't mean that the center may have split
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
dart.
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 uh link or an embedded link within our system,
but it's providing a illegitimate or spoofing link.
If the user were to click on it, they would end up at malware.r.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
ease to an unwanted or unauthorized 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 CYSA
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 D
mark protocol,
the DKIM or domain key identified mail as well as sender policy framework or
SPF these protocols you should expect to see on your CYS A plus exam.
Make sure that you understand the acronyms associated with
them and how that technology is pulled up.
If you can do that,
you should be good for those scenario based questions within your cys A exam.