1. Email Monitoring (Introduction)
In this section of the course, we’re going to discuss COVID email monitoring. Now, our focus in this section is going to continue to be in domains three and four, with objectives three one and four three. Again, objective three states that, given a scenario, you must analyses data as part of security monitoring activities. In this particular section, we’re going to focus on the security monitoring activities associated with conducting email analysis. Our second objective is #4, which states that given an incident, you must be able to analyses potential IOCs or indicators of compromise. So this is going to focus on your ability to conduct email analysis within your organization.
As we move through this section, we’re going to start with how to conduct your analysis of an email monitoring tool’s output. Then we’re going to focus on the different types of indicators of compromise, or IOCs, that are used to determine if email phishing or impersonations have occurred within your organization. Following that, we’ll look at how to conduct a malicious data analysis on an email header or email content. Then we’re going to focus on the proper configuration of your email servers for additional security, how to conduct an analysis of an SMTP log, and how to secure your emails using SMIM and digital signatures. Finally, I’m going to perform another hands-on demonstration, this time showing you how to analyse an email’s header to determine if an indicator of compromise, or IOC, can be identified within it. It’s going to be a fun section as we dive deep into determining how secure your email really is inside your organization, because this is such a common attack vector that’s used by threat actors as part of their social engineering campaigns using techniques like fishing, spearfishing, and whaling against your users. Let’s get started.
2. Email IOCs (OBJ 3.1)
Email indicators are a compromise. Now, email issues are on the rise year after year. Spam and phishing are common social engineering attacks that use email as their delivery vector, and you’ve already learned about them in your previous A Plus, Network Plus, and Security Plus studies. To recap, spam is defined as unsolicited and unwanted junk email sent in bulk to an indiscriminate recipient list. Now, the reason why they send things out in a spammy manner is because if you cast a wide net, you’ll catch some people. And that’s the idea behind spam.
Now this goes a step further when you start talking about phishing. Phishing is the fraudulent practise of sending out emails purporting to be from a reputable company in order to induce individuals to reveal personal information such as passwords or credit card numbers. This occurs frequently as part of spam, but with more malicious intent, it becomes phishing. Now, one of the big things about phishing is that you have to have a pretext. Now a pretext is a form of socialengineering in which the individual lies and providesfalse motive to obtain privileged data. You’ve probably seen phishing emails that use a pretext like this one, for instance, “I’m from PayPal,” and “Your account has been compromised.” You need to click this link to set something up or fix something, or if there’s been this big charge that’s happening, you need to click here to verify it. Those types of things happen, and this is just a way of doing spam and phishing using a pretext that is somewhat believable.
Now, if we take it a step further, we can move into spear phishing. Now with spear phishing, we’re dealing with an email spoofing attack that targets a specific organisation or individual by seeking unauthorised access to sensitive information. For example, let’s say your bank has been compromised in the past. Now the attackers have a list of all the people who use that bank. So now they can specifically target people who are customers of that bank because they know who they are, and they can use the pretext of being from that bank to target a specific list of people who are customers of that bank. For instance, if you get a spear phishing email saying there’s something wrong with your Bank of America account and click here to log into the website to fix it, you’re more likely to do that if you’re a Bank of America customer.
I don’t bank with Bank of America, so if I got that through a generic phishing campaign, I would just ignore it because I know it’s not my bank. That’s the idea behind dealing with spear fishing. It’s a little bit more targeted than a regular fishing attack. Now this all relies on the concept of impersonation. The idea behind a lot of these attacks is to try to trick someone into giving us some information. If we can get some information about you, like your name, your email, your password, your login, and things like that, that would be great. We can then use it to impersonate you. and we deal with impersonation. This is an attack in which an adversary successfully assumes the identity of one of the legitimate parties in a system or in a communications protocol. So for example, if I have figured out a particular person who works at your company and I can send an email pretending to be them, I can impersonate them and get you to do things for me. When an attacker does this, it’s usually part of a business email compromise or a VEC.
Now, when you’re dealing with a business email compromise, this is an impersonation attack in which the attacker gains control of an employee’s account and then uses it to convince other employees to perform fraudulent actions. For example, if somebody used a spear phishing campaign to convince one of my employees to click the link and take over their account, Now they can send emails as if they’re one of my employees, and if they send me an email as if they’re one of my employees from the employee’s account, saying, “Hey, you need to release funds to pay XYZ vendor,” If I’m not careful, I could say, “Okay,” and I could send the money to that vendor.
Well, that vendor isn’t really a vendor; it’s one of their friends, to whom we’ve now sent that money to.And this is the whole idea behind a business email compromise. Another way this is done is by using email spoofing. Now, with email spoofing, you can actually send out the message and make it look like it’s coming from a particular person. So, once again, if I were able to use social engineering to gather information and I knew who your chief financial officer was, I would know their email address, their name, and I might even have some of their previous emails so I could mimic their writing style. I can then spoof you and make you think that I am your Chief Financial Officer as an attacker, tell you that you need to send a payment from one place to another, and give you the routing information. And you would fall for it, right? Especially if you aren’t cautious about verifying whether or not the email came from them. Now, there are a couple of ways that this email spoofing can occur. One of the most common is known as “forwarding.”
When you’re dealing with forwarding, a phishing email is going to be formatted. So it appears to have come as part of a reply or a chain. So, for example, if I know somebody who works in your office who may not be the CFO, let’s say it’s not the head person, but instead it’s their assistant, I can then forward the email saying, “From the CFO,” they said, “transfer money from X account to Y account.” Regarding this assistant, And then you have the forward chain below that. That looks like it came from the CFO. Well, whether it did or not, if it looks like it, you may fall for that. And that’s the idea of “forwarding,” where you basically compromise a lower-level employee and then forward the email of what is supposedly a higher-level employee to get people to do what you want. Now, many spoofing attempts can be detected by a close examination of the internet headers that are attached to a message. When you open up an email, there is this hidden header that you really don’t see. If you use gmail, for example, at the top you’ll see the to line, the CC line, the from line, and the subject line. But there is a lot more to it than that. And that’s all there is to the email message Internet header. And we’ll go over that in the next lesson, as well as how to analyse them.
3. Email Header Analysis (OBJ 3.1)
Email indicators are a compromise. Now, email issues are on the rise year after year. Spam and phishing are common social engineering attacks that use email as their delivery vector, and you’ve already learned about them in your previous A Plus, Network Plus, and Security Plus studies. To recap, spam is defined as unsolicited and unwanted junk email sent in bulk to an indiscriminate recipient list. Now, the reason why they send things out in a spammy manner is because if you cast a wide net, you’ll catch some people. And that’s the idea behind spam. Now this goes a step further when you start talking about phishing. Phishing is the fraudulent practise of sending out emails purporting to be from a reputable company in order to induce individuals to reveal personal information such as passwords or credit card numbers. This occurs frequently as part of spam, but with more malicious intent, it becomes phishing. Now, one of the big things about phishing is that you have to have a pretext. Now a pretext is a form of socialengineering in which the individual lies and provides false motive to obtain privileged data. You’ve probably seen phishing emails that use a pretext like this one, for instance, “I’m from PayPal,” and “Your account has been compromised.”
You need to click this link to set something up or fix something, or if there’s been this big charge that’s happening, you need to click here to verify it. Those types of things happen, and this is just a way of doing spam and phishing using a pretext that is somewhat believable. Now, if we take it a step further, we can move into spear phishing. Now with spear phishing, we’re dealing with an email spoofing attack that targets a specific organisation or individual by seeking unauthorised access to sensitive information. For example, let’s say your bank has been compromised in the past. Now the attackers have a list of all the people who use that bank. So now they can specifically target people who are customers of that bank because they know who they are, and they can use the pretext of being from that bank to target a specific list of people who are customers of that bank. For instance, if you get a spear phishing email saying there’s something wrong with your Bank of America account and click here to log into the website to fix it, you’re more likely to do that if you’re a Bank of America customer.
I don’t bank with Bank of America, so if I got that through a generic phishing campaign, I would just ignore it because I know it’s not my bank. That’s the idea behind dealing with spear fishing. It’s a little bit more targeted than a regular fishing attack. Now this all relies on the concept of impersonation. The idea behind a lot of these attacks is to try to trick someone into giving us some information. If we can get some information about you, like your name, your email, your password, your login, and things like that, that would be great. We can then use it to impersonate you. and we deal with impersonation. This is an attack in which an adversary successfully assumes the identity of one of the legitimate parties in a system or in a communications protocol. So for example, if I have figured out a particular person who works at your company and I can send an email pretending to be them, I can impersonate them and get you to do things for me. When an attacker does this, it’s usually part of a business email compromise or a VEC.
Now, when you’re dealing with a business email compromise, this is an impersonation attack in which the attacker gains control of an employee’s account and then uses it to convince other employees to perform fraudulent actions. For example, if somebody used a spear phishing campaign to convince one of my employees to click the link and take over their account, Now they can send emails as if they’re one of my employees, and if they send me an email as if they’re one of my employees from the employee’s account, saying, “Hey, you need to release funds to pay XYZ vendor,” If I’m not careful, I could say, “Okay,” and I could send the money to that vendor. Well, that vendor isn’t really a vendor; it’s one of their friends, to whom we’ve now sent that money to.And this is the whole idea behind a business email compromise. Another way this is done is by using email spoofing. Now, with email spoofing, you can actually send out the message and make it look like it’s coming from a particular person.
So, once again, if I were able to use social engineering to gather information and I knew who your chief financial officer was, I would know their email address, their name, and I might even have some of their previous emails so I could mimic their writing style. I can then spoof you and make you think that I am your Chief Financial Officer as an attacker, tell you that you need to send a payment from one place to another, and give you the routing information. And you would fall for it, right? Especially if you aren’t cautious about verifying whether or not the email came from them. Now, there are a couple of ways that this email spoofing can occur. One of the most common is known as “forwarding.” When you’re dealing with forwarding, a phishing email is going to be formatted.
So it appears to have come as part of a reply or a chain. So, for example, if I know somebody who works in your office who may not be the CFO, let’s say it’s not the head person, but instead it’s their assistant, I can then forward the email saying, “From the CFO,” they said, “transfer money from X account to Y account.” Regarding this assistant, And then you have the forward chain below that. That looks like it came from the CFO. Well, whether it did or not, if it looks like it, you may fall for that. And that’s the idea of “forwarding,” where you basically compromise a lower-level employee and then forward the email of what is supposedly a higher-level employee to get people to do what you want. Now, many spoofing attempts can be detected by a close examination of the internet headers that are attached to a message. When you open up an email, there is this hidden header that you really don’t see. If you use gmail, for example, at the top you’ll see the to line, the CC line, the from line, and the subject line. But there is a lot more to it than that. And that’s all there is to the email message Internet header. And we’ll go over that in the next lesson, as well as how to analyse them.
4. Email Content Analysis (OBJ 3.1)
Email server security In this lesson, we’re going to start talking about some of the security measures that you can implement on your email servers. Now, the first thing you have to think about is that spoofing attacks can be mitigated by configuring authentication for your email server systems. And there are a couple of ways to do this, and we’re going to talk about those in the lesson. We have things like SPF, DKIM, DMARC, and cousin domains. Let’s talk about each of these as we go through this lesson. First, there’s SPF, or Sender Policy Framework.
This is a DNS record that identifies the host authorized to send mail for the domain, and there’s only going to be one allowed for each and every domain. Now, as you look at them, you’re going to have something that looks like this. And this is a DNS record called a text record. You’ll notice it has the at sign and then says V equals SPF 1, which is Sender Policy Framework 1. It’s the first one. It then has MX, which is the mail server record. “Include underscores Google.com and include colon.Email freshdest.com,” it continues. All Now, what is this telling you? Well, this is actually the SPF record for the MYCE email server. Now why do we have Google.com there? Well, it’s because we use the G Suite from Google. And so Google is our email service provider.
We don’t run our own email server. Instead, we let them do it, and we’ve given them authorization to do that by including that SPF statement. Now the second one there, you might be wondering, “What’s that for?” I thought you could only have one. Well, you can only have one SPF statement, but this entire thing is one line when written in DNS. And this whole thing, from text all the way to “all,” is one single line. That is one single SPF statement. I can authorize multiple servers to send on my behalf, but I can only do it in one DNS line, as you see here. Fresh desk is our trouble ticketing system. If you email support at Deon training, it’s going to go to Fresh desk. But if you email my personal email at Deon training, it’s going to go over to Google because that’s who does our personal emails for our company. And so you have to include both of those and anything else that’s going to be authorized to be sent on your behalf inside this statement. Now, what is this SPF statement really doing?
Well, when you receive an email from me, your server is going to go check the DNS record and say, “Does the email address, the envelope return header that I have that return path when I look that up, match one of the servers inside of this mail record?” If it does, you’re authorized to receive it, and it’s likely not spam. If it doesn’t, that means someone might be trying to spam a domain and pretend they’re me sending it to you. And this is all done in the background by your email service provider before you get my emails. Now, the next thing we need to talk about is DKIM, or Dim. Now, this is the domain key identified in the mail. This provides a cryptographic authentication mechanism for mail using a public key published as a DNS record. Now, when you look up an SPF or DKIM, you’re going to see something like this. Here’s an example showing you the mail for Adobe.com. You can see the “D” mark at the top, which we’ll talk about in a minute. You’ll see the SPF, which we just talked about, and then you’ll see DKIM, which is what we’re talking about. Now notice that DKIM looks like base 64 encoding.
Essentially. It’s basically a very long cryptographic authentication key. and you can see it there on the screen. Now, DKIM can either replace or be used with SPF. When you configure DKIM, your domain MTA will calculate a hash value of the selected message headers when you send an outgoing email. It’s then going to sign that hash using its private key. Now, this key here is what’s known as your public key. And so when you send this message over, it has that hash value that’s been encrypted. When it gets it, it’s going to decrypt that hash value. It’s going to run your headers through the hash again and compare the two. If they match, that means that nothing was modified in transit, and they can trust that message. Essentially, it’s like a digital signature for an email. But this is done by the servers, not by the individual account. And so you’re verifying that the server actually sent it, not that the person actually sent it. That’s the idea here. When dealing with a DKIM, the next one we’ll go over is DMARC. And DMARC is the domain-based message authentication, reporting, and conformance service.
This is basically a framework. And this framework is used for ensuring proper application of SPF and DKIM by utilising a policy that’s published as a DNS record. And I showed you that very briefly in the last image on your screen when I showed you the Dmark as the top line of that image. If you want to go back and take a look at that, you can at this time. Now, when you’re dealing with DMARC, you can use this either with SPF, with DKIM, or using both. Because, remember, SPF and DKIM don’t have to be used together. You can use one or the other, or you can use both. And DMARC is going to be used with one, the other, or both. Now, when you’re dealing with DMARC, this is what it looks like. So how does all of this work together? Well, first you have to make sure that your SPF, your DKIM, and your DMARC are all on the DNS server. Once you have all those records there, that’s what starts this whole process.
Now, once you’ve done that once, everything else is going to follow up each and every time you want to send a message. In this example, we’re going to send two messages being sent.one from the SMTP server, which is authorised and being shown as green, and one from an adversary who is trying to spoof your domain, which is going to be shown in red. Let’s start with the one that’s authorised here. It’s listed as A and B. Your sender is going to send that message over to the MTA. It goes to the MTA, which is your message transfer agent, and it’s going to end up taking that message with the SPF or DCM header in it. Now, let’s stick with this message for a minute, and then we’ll come back to the adversary. Once the MTA has that message, it’s going to go ahead and look at that message and process that message. When it does that, part of that is going to be looking up the sender DMARC policy and the SPF and DCM records via DNS, just like we talked about in the last three or four minutes here. Now, once the MTA does that, if it’s legitimate, that message can be placed into the receiver’s mailbox on the IMAP server and wait for the person to be able to read their message using their mail user agent.
That’s all good because they know this message was authentic because it compared those values against the SPF, the DKIM, or the D mark based on the policy that was set up. Now, if we look at the adversary, on the other hand, when they send the message, it still goes to the MTA because it has to get to the MTA to get to that end user. Once it gets there, though, the MTA is going to check it against that DMARC policy, looking at the SPF or DCM records. Once it does that, if they don’t match, it’s going to reject that message, delete it, or quarantine it, and it throws it away, as you can see in Figure 5. Again, this is the way this stuff works. And by using DKIM, DMARC, and SPF together, we can add some security to organizations. Now, using SPF, DKIM, and DMARC does not solve the problem of cousin domains, though. Now, what’s a cousin domain, you might ask? Well, a cousin domain is a domain name system domain that looks similar to another name when it’s rendered by a male user agent.
5. Email Server Security (OBJ 3.1)
Email server security In this lesson, we’re going to start talking about some of the security measures that you can implement on your email servers. Now, the first thing you have to think about is that spoofing attacks can be mitigated by configuring authentication for your email server systems. And there are a couple of ways to do this, and we’re going to talk about those in the lesson. We have things like SPF, DKIM, DMARC, and cousin domains. Let’s talk about each of these as we go through this lesson. First, there’s SPF, or Sender Policy Framework. This is a DNS record that identifies the host authorised to send mail for the domain, and there’s only going to be one allowed for each and every domain. Now, as you look at them, you’re going to have something that looks like this. And this is a DNS record called a text record. You’ll notice it has the at sign and then says V equals SPF 1, which is Sender Policy Framework 1. It’s the first one. It then has MX, which is the mail server record. “Include underscore SPF Google.com and include colon. Email freshdest.com,” it continues.
All Now, what is this telling you? Well, this is actually the SPF record for the MYCE email server. Now why do we have Google.com there? Well, it’s because we use the G Suite from Google. And so Google is our email service provider. We don’t run our own email server. Instead, we let them do it, and we’ve given them authorization to do that by including that SPF statement. Now the second one there, you might be wondering, “What’s that for?” I thought you could only have one. Well, you can only have one SPF statement, but this entire thing is one line when written in DNS. And this whole thing, from text all the way to “all,” is one single line. That is one single SPF statement. I can authorise multiple servers to send on my behalf, but I can only do it in one DNS line, as you see here. Freshdesk is our trouble ticketing system. If you email support at Deontraining, it’s going to go to Freshdesk.
But if you email my personal email at Deontraining, it’s going to go over to Google because that’s who does our personal emails for our company. And so you have to include both of those and anything else that’s going to be authorised to be sent on your behalf inside this statement. Now, what is this SPF statement really doing? Well, when you receive an email from me, your server is going to go check the DNS record and say, “Does the email address, the envelope return header that I have that return path when I look that up, match one of the servers inside of this mail record?” If it does, you’re authorised to receive it, and it’s likely not spam. If it doesn’t, that means someone might be trying to spam a domain and pretend they’re me sending it to you. And this is all done in the background by your email service provider before you get my emails. Now, the next thing we need to talk about is DKIM, or D.Kim. Now, this is the domain key identified in the mail. This provides a cryptographic authentication mechanism for mail using a public key published as a DNS record. Now, when you look up an SPF or DKIM, you’re going to see something like this. Here’s an example showing you the mail for Adobe.com.
You can see the “D” mark at the top, which we’ll talk about in a minute. You’ll see the SPF, which we just talked about, and then you’ll see DKIM, which is what we’re talking about. Now notice that DKIM looks like base 64 encoding. Essentially. It’s basically a very long cryptographic authentication key. and you can see it there on the screen. Now, DKIM can either replace or be used with SPF. When you configure DKIM, your domain MTA will calculate a hash value of the selected message headers when you send an outgoing email. It’s then going to sign that hash using its private key. Now, this key here is what’s known as your public key. And so when you send this message over, it has that hash value that’s been encrypted. When it gets it, it’s going to decrypt that hash value. It’s going to run your headers through the hash again and compare the two.
If they match, that means that nothing was modified in transit, and they can trust that message. Essentially, it’s like a digital signature for an email. But this is done by the servers, not by the individual account. And so you’re verifying that the server actually sent it, not that the person actually sent it. That’s the idea here. When dealing with a DKIM, the next one we’ll go over is DMARC. And DMARC is the domain-based message authentication, reporting, and conformance service. This is basically a framework. And this framework is used for ensuring proper application of SPF and DKIM by utilising a policy that’s published as a DNS record. And I showed you that very briefly in the last image on your screen when I showed you the Dmark as the top line of that image. If you want to go back and take a look at that, you can at this time. Now, when you’re dealing with DMARC, you can use this either with SPF, with DKIM, or using both. Because, remember, SPF and DKIM don’t have to be used together. You can use one or the other, or you can use both. And DMARC is going to be used with one, the other, or both. Now, when you’re dealing with DMARC, this is what it looks like.
So how does all of this work together? Well, first you have to make sure that your SPF, your DKIM, and your DMARC are all on the DNS server. Once you have all those records there, that’s what starts this whole process. Now, once you’ve done that once, everything else is going to follow up each and every time you want to send a message. In this example, we’re going to send two messages being sent.one from the SMTP server, which is authorised and being shown as green, and one from an adversary who is trying to spoof your domain, which is going to be shown in red. Let’s start with the one that’s authorised here. It’s listed as A and B. Your sender is going to send that message over to the MTA. It goes to the MTA, which is your message transfer agent, and it’s going to end up taking that message with the SPF or DCM header in it. Now, let’s stick with this message for a minute, and then we’ll come back to the adversary. Once the MTA has that message, it’s going to go ahead and look at that message and process that message. When it does that, part of that is going to be looking up the sender DMARC policy and the SPF and DCM records via DNS, just like we talked about in the last three or four minutes here.
Now, once the MTA does that, if it’s legitimate, that message can be placed into the receiver’s mailbox on the IMAP server and wait for the person to be able to read their message using their mail user agent. That’s all good, because they know this message was authentic because it compared those values against the SPF, the DKIM, or the D mark based on the policy that was set up. Now, if we look at the adversary, on the other hand, when they send the message, it still goes to the MTA because it has to get to the MTA to get to that end user. Once it gets there, though, the MTA is going to check it against that DMARC policy, looking at the SPF or DCM records. Once it does that, if they don’t match, it’s going to reject that message, delete it, or quarantine it, and it throws it away, as you can see in Figure 5. Again, this is the way this stuff works. And by using DKIM, DMARC, and SPF together, we can add some security to organizations. Now, using SPF, DKIM, and DMARC does not solve the problem of cousin domains, though. Now, what’s a cousin domain, you might ask? Well, a cousin domain is a domain name system domain that looks similar to another name when it’s rendered by a male user agent.
6. SMTP Log Analysis (OBJ 3.1)
SMTP log analysis. So we’ve talked a lot about emails so far. We’ve looked at some headers; we’ve looked at phishing; we’ve looked at things like Kim and the DNS policies. But we really haven’t talked about the email servers themselves and going through their logs. And that’s what we’re going to focus on in this lesson. Now, SMTP logs are typically going to be formatted in request-response fashion. Now, what this means is that you’re going to get a series of logs that are going to show you a couple of pieces of information. such as the time of the request for a response We’ll also see the recipient’s address, the message’s size, and the current state. Now, as we go through the lesson, we’re going to talk about some of these in more depth. For instance, we don’t really need to talk about the time of the request for a response because that’s pretty easy. It depends on the time, the address, who you send it to, and the size of the message.
But status codes—that’s something we should spend a little bit of time on. Let’s talk about some of the specific status codes you might want to know if you’re doing a log analysis first. Code 220. This indicates that the server is ready. Essentially, I’ve received this code, and I am ready to do some kind of processing on the thing you’re going to send me. I’m ready to take something in; send it to me. That’s what that means. When we deal with code 250, this indicates that the message has been accepted. So if I send a message over to your SMTP server, it’s going to send you back a status code of 250 saying I have received it and I’ve accepted it. You don’t have to send it again because, usually with email, if it bounces back, they’re going to try and try again until it finally gets successful or a certain amount of time has passed. The next one we’re going to talk about is code four, two, one. and this indicates the service is not available.
Maybe you’re trying to send a message to a server, and that server happens to be down right now. If so, you’ll get a code of 4, 2, 1. Maybe they’ve turned off the server. Maybe the server is having an issue; maybe, for some reason, it just can’t process it. Whatever the cause, that is error code 4201. The next one is code 450. Now code 450 indicates that the server cannot access the mailbox to deliver a message. Maybe it doesn’t have permissions; maybe the mailbox doesn’t exist. Perhaps you tried to send something to [email protected], and that’s not really my email. So it’s going to bounce back and say, “I can’t access that mailbox,” or for some reason it just can’t access my real mailbox right now because there’s an issue. The next thing we want to talk about is 451. And code 451 is going to indicate that the local server aborted the action due to a processing error. Something happened on that server, and it’s just not going to work. So it tells you I’m not working right now. Sorry. Then we have code 452.
This indicates that the local server has insufficient storage space available. So what does this mean? It means your drive has filled up. For instance, maybe you have a 1 TB hard drive. And that hard drive is now at 999gb.And you just sent a very large message, and it just doesn’t have room to store it. That’s what code 452 is. You should never get that code, but it happens. Now let’s take a look at some logs and what they look like. Here’s an example of a log. You’ll see smtpd on the left, which is the Linux SMTP server, the SMTP daemon. You’ll see the log entry there in the second column. And as you keep going to the right, you’re going to see the date, the time, the IP address that I received it from, and then the messages. And these are really what I want to focus on, over here on the right side. So as we see the first line, you’ll see 220.
Now what does that mean? It means that this server that we’re looking at, our server, sent out message 220 saying I am ready to receive something from the mail server at 500 and fivesupport.com, and I sent it out over SMTP. Then we get to receive it—a message from SMTP OpenMail foo. Now our third line says “sent 250.” What does “250” mean? 250 means I have accepted your message. So I received the message from mail 501(c)(3) support, and I have accepted it. Now I’m going to log that I have received that message, and I received the message where I received it from getrich at Bitminor Foo and I saw the size of it: 204, 80, zero. And I see that again: a 250-authenticated login, which means I’ve received it and I’m good. I then send a 250 indicating that I’ve accepted it, and then state that I received recipient Sam at five one, five support, and sent 250. Okay. Meaning? I received it. I’m sending back the acknowledgement of received data: three, five, four, okay, send me what you need, and then I get sent 250 again. I accepted that message. I’m in line. I waited 11 seconds. Then I received, and then I quit.
And then I sent two, two, one, which is the goodbye message. So this is basically the handshake that you see, and I’m ready to receive it. I’ve received it. I’ve got it from here. I got the information; everything’s good. OK, quit buying. This is normal. But the only thing that looks really out of the ordinary to us here would be the fact that this mail came from Bitminor Foo. Getrichat, which is most likely a spam email in this case. And then we might want to go look at Sam’s mailbox and make sure that Sam is not clicking on that link because it might have some bad things in it. And this is the way you do a basic SMTP analysis as you read these logs. As I said, reading through is pretty easy. What you want to look at are some of the major codes. Things like 220 and 250 are very common. Some of the other ones are here; you really don’t need to know the specifics. like three, five, four, or two, two, one. I mentioned a lot of codes in this lesson, but really, if you just focus on 220 and 250 for the exam, you’re going to do just fine.
7. Email Message Security (OBJ 3.1)
Email message security Earlier, we talked about Mime, but there’s another extension that we can use, known as S Mime. S Mime is the secure, multipurpose internet mail extension. And this is the ability for an email to have an encryption standard that includes digital signatures and public key cryptography in addition to traditional Mime communications. Now, for this to work, every user has to be issued a digital certificate containing his or her public key in order for them to use S Mime. Now, in addition to that public key, there’s going to be a matching private key. Now, this private key has to be kept secret by the user. Nobody else in the world can ever know what their private key is, but that public key is one they should have and share with everybody else. Let’s talk about how this works. Let’s assume I want to send Mary some information. Well, if I wanted to do that using S Mime, first I would have to send Mary my digital certificate that contains my public key and validates my digital ID, my distinguished subject name, and my email address.
And then I’m going to sign this message using my private key. After that, Mary is going to use the public key in the certificate to decode my signature and the signature of the CA, which is the authority that signs those public and private keys. And this is going to validate my digital certificate and my digital ID. And then she can decide if she’s going to trust me or not. In this case, she would, because she saw that it was validated using the CA. Then we go into the third step, and Mary is going to respond with her digital certificate, which has her public key, and I am going to be able to follow the same process, and I’ll be able to start deciding to trust Mary. So at this point, both Mary and I have each other’s public key. Now, both Mary and I have each other’s certificates in our trusted certificate stores, and this means we both have each other’s public keys or a copy of them. So now we can start sending information securely. Let me show you how that’s going to work. So now both Mary and I have each other’s public key certificates inside of our trusted certificate stores. So at this point, if we start encrypting data without using private keys, the other one can decrypt it using our public keys because we’ve already made this trade.
Let’s take a look at how this looks when I want to send an email securely. Now, there are two different ways I can talk about security when I’m sending an email. One is integrity and nonrepudiation, and the other is confidentiality. Let’s take them one at a time. First, we’re going to talk about integrity and nonrepudiation. Let’s say I want to send a message to Mary, but Mary wants to make sure that only Jason could have sent this information. Well, to make sure that happens, What we’re going to do is I’ll take my message and make a digital hash of it. I’m going to take that hash and encrypt it using my private key. And then I have this plain text message and this encrypted hash of the text, and I send them both over to Mary. When Mary gets it, she’s going to use the public key that she just got for me in our earlier exchange from her trusted key store to unlock my private key. Because remember, if you encrypt with private, you have to decrypt with public.
This is something you learn in your security plus classes. At this point, we now have the plain text of the message, which has always been plain text. And we now have the plain text of the hash. Mary’s computer is going to run a hash against the message itself. She’s then going to compare that hash to the one I sent. If those two values match, that means this message has not changed during transit. And we have integrity, because the hash that I sent her matches the hash that she calculated based on that message. Now, how do we get nonrepudiation? Well, what did I use to sign that hash? I used my private key. Who is the only person in the world who has that private key? Me. And therefore you have nonrepudiation because only Jason could have sent this message because Jason used his private key to encrypt that hash. That’s why using a digital signature, which is an encrypted hash of the digital message, and having it sent over to the other person gives you integrity and prevents repudiation. But that doesn’t stop anyone from actually reading this message. So there’s no confidentiality because that email I sent was unencrypted or decrypted the entire time and sent in plain text. So we need to do something else to give you confidentiality. And that brings us to our second part of this.
When we’re dealing with confidentiality, let’s say I want to send that same message. I’m going to do both of these at the same time, but we’re taking the confidentiality part. Now, I’m going to use Mary’s public key. I’m going to take my message at the top of my email and I’m going to encrypt it. Now, I take that encrypted email that’s encrypted with Mary’s publickey, which means even I can’t read it at this point, and I’m going to send it over to Mary. When she gets it, she’s going to unlock it using her private key. Now, the great thing about this is that the only person in the whole world who has that private key is Mary. So she is going to be the one who’s able to read that message. Even if they could grab it in transmission, it’s going to be encrypted, and they won’t be able to read it. Now, could they read some part of this message? Yes, they could read the hash that I digitally signed. Why? because I encrypted it with my private key. Going back to our last section here And when I encrypted something with my private key, like that digital hash, anyone in the world could read it, but they couldn’t read the message associated with only the hash value. And that’s why we put these two things together by using the integrity and nonrepudiation of the hash along with the confidentiality of using Mary’s public key for the message.
By using both of these together, this is going to give you the digital signature of the email for encryption and non-repudiation and the digital encryption of the message using Mary’s public key. Now, the email client is going to be able to determine for you if your digital signature is valid, and it will display an icon for you when it does that. As I said in my explanation, when Mary got that first message from me, her machine took that message, ran it through the hash, and compared it against the hash that I had digitally signed. When it does that, if they match, you’re going to see something that looks like this. In this case, you could see it says “signed by the person who signed it” and has that little ribbon off to the right side. This means that the signature was valid, and everything was fine. Now, if Mary’s machine went through and checked that and it didn’t have a hash that matched the one that was sent, then she’s going to see something like this. It’s going to be an email with a red X. This is going to tell you that the message was not sent with a digital certificate. And that’s the difference here. When you see that little ribbon, you know that message was digitally signed by that person. When you see something that looks like this, it means you don’t.
8. Analyzing Email Headers (OBJ 4.3)
Analyzing email headers In this lesson, we’re going to talk about email and dig into looking at some headers. Now, let’s go in and look at a legitimate piece of email. This is when I set up in my test environment, and I’m sending just an email from myself to myself. Now here, you’re going to see that there’s a text message that went to Sam at 550 support. When we go in and look at the headers of this, we’re going to be able to see all of the different pieces that are important to us. Things like the return path received from the date and content type Now if we look at the return path, this is the address that will normally receive the notifications when the email message is not deliverable. So it’ll say, “Hey, I couldn’t get there,” and it’ll send a message back to the server.
Normally, this is going to be the same as your sender’s email, but it could be changed by a server. This doesn’t necessarily mean that it’s malicious. The next thing we want to look at is reception. Now under “received,” you’re going to see a list of all the hosts that have touched this message as it tried to deliver it. You’re going to start out by sending them in order, going from the most recent to the least recent. This way, you can see the entire path of where it’s gone. Because I’m running everything in a lab environment, it really only went from one server in my case. But in the real world, you’ll see this go from server to server until it finds its way from one ISP to the next. Then we’re going to look at the background. Now this is your sender’s address. Now in this case, this is a genuine message, but it is possible to actually spoof this from the address, and we’re going to look at some of that as we go through and analyse headers later on. The next thing we want to look at is the date.
And again, this is just the date that this was sent. And you are going to notice there is a time zone offset here based on where the sender sent the message from. Finally, there is content type. Now if this is a plain text message, it can’t have any exploits. But if you’re using something like HTML or rich text-formatted messages, those can have attachments and embeds inside the message that could carry malicious links and malicious payloads. All right. Now this time we’re going to go ahead and send a phishing email. In this case, we’re going to impersonate a local user because we think that this server has an open relay because they haven’t secured their email server. So I can go in and change my email address. So instead of having to go from host master at fiveonefive.net, I’m going to go ahead and change that to Bobby at Five One Fivesupport.com.When I do that and press Okay, I will be able to send messages as Bobby. Now, I’m going to send a phishing email to Sam at Five One Five Support, posing as a legitimate employee of Five One Five Support.
Now Sam will take on Bobby, and when I send this message, I’m going to attach the evilputty exe file from my downloads folder. This way, he’s going to have a malicious payload. So if he opens that email and runs that exe, I’m going to have control of his system. Now let’s go back to my original machine and see what happens when Sam tries to get that email. Notice here that the email was not delivered. That’s strange. Let’s go ahead and take a look at our SMTP logs to figure out why. All right, here we are in our SMTP logs. We’re going to go ahead and look at our mail server administration and go to Settings, then Logging, then Show Logs. Here I can see the most recent log file as I open it up. Now, towards the end of this file, you’re going to see that five-factor SMTP authentication is required. Now what does that mean? Well, it means this local email server refused the connection when I tried to send that email as Bobby. Why did it do that? Because I never authenticated myself with the server. because this server doesn’t have an open relay.
It requires authentication by users and host IP ranges whenever they try to connect to it. So when I tried to send something as Bobby at Five One Five Support, it went ahead and stopped me because I never logged in with Bobby’s username and password. Now, just to show you what happens here, I’m going to go ahead and log in as Bobby on his account. Now, when I log in as Bobby with his password and open up his email account, I can see there’s a non-delivery report. This is because that return path was set as his email address. So when the server wouldn’t send my phishing email on to the next person, Bobby got the kickback message going to him. And so if he saw this, he could tell the security folks, and they could do some additional research to figure out why the delivery didn’t happen. Or in this case, if it wasn’t a message they sent, he should report to security that this is suspicious activity and that someone is trying to create a phishing campaign using his email.
