CompTIA CYSA+ CS0-002 – Analyzing Network IOCs Part 1

1. Analyzing Network IOCs (Introduction)

In this section of the course, we’re going to discuss how we can detect and analyze network indicators of compromise. In this section, we’re going to continue our focus on domain four, but this time we’re going to be looking at Objective 4. 3. Objective 4. 3 states that given an incident, you have to analyze potential indicators of compromise. In this section of the course, we’re going to focus only on network IOCs, but then we’re going to move into host related, application related and lateral movement, and pivoting IOCs. In the next few sections of this course, as we move through this section, we’re going to start with looking at exactly what a network based IOC is and how they’re used. Then we’re going to move into some common IOC types and how to identify them.

This includes traffic spikes, beaconing irregular, peer to peer communication channels, rogue devices, scans and sweeps, and nonstandard port usage. We’ll also spend a little bit of time discussing common TCP and UDP ports because, after all, if you don’t know what a normal port is, it’s really hard to understand what might be considered a nonstandard port usage right now. We’re also going to take a look at data, exfiltration techniques and covert channels inside this section as well. Finally, I’m going to perform a demonstration where we’re going to analyze the network IOCs together in a lab so you can better understand what various attacks look like when you’re working as an analyst. All right, let’s start analyzing networks to see if we can find any indicators of compromise.

2. Analyzing Network IOCs (OBJ 4.3)

Analyzing network IOCs or indicators of compromise. Now, in this section we’re really going to focus on all of the different ways of identifying bad behavior on a network. Once we find an indicator of compromise we can then use that to create defenses against these different types of attacks and then we can also use those inside of our threat hunting. Now, there’s lots of reasons for using IOCs. We can use it to create defense offenses or do threat hunting. We can use it for instant response and forensic investigations and lots of other things.

Now, while the way we’ll use those different IOCs may be very different the way we learn about these IOCs and gather them and analyze them is going to be very much the same.Now, when we start dealing with network related IOCs there are lots of different ones out there. For example, what if we start seeing things like port scanning and sweeps? If we see that, then it may be the indicator that there’s an attack coming next. We might identify things like nonstandard port usage. For example, maybe I’m seeing SSL being used on some port for web traffic that isn’t four, four three. Well, that would be something that would flag as something I should look for.

And if the same attacker uses the same type of ports every single time for the same type of malware that would be a good indicator of compromise we could use. Maybe we start identifying a covert channel. Like, for instance, we start seeing data that’s being sent out over a ping packet because normally ping packets don’t carry data. And so that would be something that would be unusual. And if we identify that, that might be a sign of a data exfiltration or beaconing or C two or something like that. Or maybe we start looking around our network and we start seeing devices that we don’t recognize. For instance, there’s a new wireless access point or a new wireless network out there or there’s a new switch.

Any of these things could be rogue devices and that could have been something that’s an indicator of an insider threat. Now, that insider might have had intention with this or it might have just been something they were doing for convenience. Either way, they’re bringing a threat to our network and it’s something that we can identify and then relate that back to the intrusion set. In this case, an insider threat. All of these things are what we’re looking for when we start analyzing networks to identify these IOCs or indicators of compromise. And as we go through the next several lessons in this course we’re going to start talking about individual IOCs and how to identify them.

3. Traffic Spikes (OBJ 4.3)

Traffic spikes. In this lesson we’re going to talk about traffic spikes and some of the things that may cause them because this could be an indicator of compromise within your network. Now, when I talk about a traffic spike, this is really any sharp increase in connection request in comparison with a given baseline. Now, I know this is a very generic statement, but it’s important that we start out generically because by default a traffic spike doesn’t have to be a bad thing. For instance, let’s take a look here. Let’s say you’re looking at your logs and you start seeing that traffic was around 100 or 200 or 300 for the first ten or 15 minutes after 01:00 A. m. .

But then it jumps up at around 115 to 125. And during that time you reach a peak of about 800 megabits per second.Then it drops down again to 200, 100 and kind of stays there through the rest of the night. Now, is this malicious? Are you under attack? Well, maybe we don’t have enough information. All we know right now is there is something anomalous this could be normal. For instance, on my server we run our backups that go from our servers to offsite cloud storage between one and 02:00 A. m. . And so if I saw this, I would then look and see where was the traffic going. And if it was going to my backup server, this would be normal because it’s going from my servers to a backup server which shows a large export of data between one and 02:00 A. m.

On my servers. Now, if it happened at one in the afternoon, that would be different. But I expected it this time. And so it really does depend what is causing that traffic spike. And that’s an important thing to consider. Now, one of the things that could cause one of these traffic spikes that would be malicious in nature would be something like a denial of service attack or a distributed denial of service attack, which is much more likely these days. Now, when you deal with a distributed denial of service attack, this is

when you’re going to have lots of different hosts all trying to connect to your server at once to waste your resources, whether that’s network resources, processor resources or memory.

Essentially, a distributed denial of service attack or DDoS is an attack that uses multiple compromised hosts, usually bots or zombies inside of a botnet, to overwhelm a service with requests or with response traffic. And by doing that, we can essentially take your machine offline by attacking it and overwhelming it. Now, one of my favorite examples to use with a denial of service or distributed denial of service attack is thinking about kids. For instance, if you’re a parent, you may have one or two or three kids. When I had one kid and they would look up and say, mommy or Daddy, I need help.

It wasn’t that big of a deal you could stop what you’re doing, help the child, and then go back to what you’re doing. Now, over time, if you have more kids, say you have two kids, it becomes a little harder. And so Mommy might get a little more overwhelmed because now she’s got two kids who are trying to get her attention at all times, going, Mommy, Mommy, mommy. And that can become overwhelming. Now, if I had three or four or five kids, or say 20 kids, because you’re an elementary school teacher, you can really get overwhelmed quickly. Now, that’s the difference when you have one kid, that’s a denial of service. Yes, you had to stop what you’re doing and take care of the child.

But as soon as you’re done, you can go right back to what you’re doing and you can recover quickly. Now, if you had two or three or five or ten or 20 kids doing this, you can become overwhelmed and it would take you a lot more time to satisfy all of their needs. And you basically can just shut down because there’s too much going on. Well, that’s what our servers do as well. Now, a DDoS can really overwhelm even the most well defended networks through the sheer volume of traffic that they’re going to be exposing you to. This means you have to come up with good Mitigation strategies and be prepared for them.

Because even if you have all the best security measures, most DDoS traffic comes at you, and it looks like legitimate traffic, so your servers want to try to answer it. Now, one of the other big problems we have with DDoS these days is that anyone can do them. So it used to be you had to actually be a developer and create this botnet, and you’d have to buy resources or hack other people’s machines and add them to your botnet. Well, nowadays people actually sell botnets, so you can actually go in for the low price of 34 99 per month. You can have access to the one month diamond plan, which will give you 3600 seconds, which is about six minutes of time to use this DDoS.

You can have two concurrent streams going at once. You can get a total network traffic of about 220 gigabits per second, and all the tools are included, and you get 24/7 support. I mean, who wouldn’t want that deal for 34 99 per month, right? This is the idea of how cheap and inexpensive these botnets have gotten, and it really takes no skill at all to use them, so anyone can. So your network has to be prepared. Now, as I said before, not all surges in traffic, meaning you have a botnet. But if you do have a large unexpected surge in traffic from Internet hosts, this could be the indication of an ongoing DDoS attack against you using a botnet. Now, it’s not a clear indication, but it is an indication.

And so you’d have to back that up with other factors. Now, what are some of those other factors? Well, you might start seeing an excessive number of time weight connections in your load balancer or inside your web server’s state table if you see that. Plus you have high numbers of Http 503 errors, which is service unavailable log events. This could indicate that a DDoS attack is occurring. Now, those are great indications that you are the victim of a DDoS attack that people are pointing at you. But how do you know you’re not part of the problem and you don’t have hosts compromised on your network that are part of this problem that are attacking somebody else? Well, if you happen to see a large amount of outbound traffic from your network, this could indicate that your network contains victimized hosts that are being used in a DDoS against other people.

And so you may want to figure out where those hosts are and get them cleaned up because you don’t want victims on your network, right? So now that we’ve talked about DDoS attacks and what they look like coming at us or going against somebody else, we have to talk about how do you measure a DDoS attack? Well, the most common way to measure it is how much bandwidth is being consumed. So you’ll do it in megabytes per second or gigabytes per second or even terabytes per second. Now, when we do this, this is also known as bandwidth consumption. And bandwidth consumption can be measured as the value of bytes that were sent or received or as a percentage of your link utilization.

For example, if you’re reading a news article about a recent distributed Denial of service attack, usually it will say something like this was a 1. 5 terabit per second attack. And that’s talking about the amount of bytes sent or received. Now, if you’re looking at internally on your organization, you’ll know what your total link size is. And so if you have a one gigabit per second connection from your server out to the Internet and you see that you’ve been using 800 megabits per second, you could say that was an 80% link utilization based on this attack. And so both those are ways you can measure it from the outside looking in or the inside looking out. In addition to a standard DDoS attack, there’s another kind out there called a DRDOs, and this is a distributed Reflection Denial of service attack.

Now, back in security, plus you probably learned about reflection attacks or amplification attacks. And that’s really what we’re talking about here. A DRDOs attack is a network based attack where the attacker dramatically increases the bandwidth sent to the victim during the attack. By implementing an amplification factor, a DRDOs attack can occur when the adversary spoofs the victim’s IP address and tries to open up connections with multiple servers. Now, by doing that, all those servers try to respond back to them. We talked about this back in Security plus as well, when we talk about the three way handshake, that occurs when you’re trying to connect to a server.

You send a sin packet. The server then will hold a space for you and send back a syn ACK. It now has resources reserved to handle your request. And then you acknowledge that by sending an AC message. And then you have a two way communication that will occur after that three way handshake. So sin, sin, AC, and then start communicating. Well, it’s like I said hi to you and you said hi to me, and then I ignored you and you’re waiting for me to say something back. You won’t hang up the phone until I say something, but I give you silence. That’s essentially what’s happening inside of this attack. Now, you don’t have to just use TCP to do this though.

There’s lots of different protocols you can use. For instance, one of the most common ones that used to be used was the ICMP attack where you would flood a server with ICMP requests, which are ping requests. Essentially, the attacker would send a ping request to the broadcast of a subnet. Then that subnet has all of the machines on it responding back to that server. This way, I send out one ping, I get back 510, 5100 computers responding to that server. Notice here the ping request. The source IP is spoofed. It’s saying, hey, I’m coming from ten one one two. But that’s actually the IP of the server. So when all those hosts on the subnet try to respond to that ping request using an echo reply, all of those replies go back to the server instead of to the original attacker.

This is the idea of an amplification, and this one uses ICMP. Now, like I said, there are lots of different amplification attacks out there using different protocols. You might use DNS. Now DNS is a good one that attackers use as well, because they can send out a bogus DNS query. And then that is only a small request for information, but the server has to give back a lot of information. For instance, if the request was tell me what you know about deontraining. com, the DNS server can come back and say I know lots about that, I know what its mail server is, and here’s its IP. I know that it has this CNAME and that CNAME and this SPF record and this TXT record, and it will give you all that information back.

And that can overwhelm a server if I send out a lot of these DNS queries and all those responses are coming back to it and we’re just taking up resources. That’s the idea here. Another amplification attack can be used with network time protocol. Now, the reason why using NTP is so effective is because a single NTP request will generate a response from the server for the last 600 machines that that server has contacted. And so if I make a request to the NTP server it’s going to send back 600 times what I asked for and so that can really overwhelm people very quickly. Now remember, as I said before, all of this is indications. It doesn’t prove there’s a DDoS attack, but it is good indications of it.

Now, when we start dealing with bandwidth consumption and traffic spikes, this can indicate a DDoS attack, but it can also be indicative of many other types too. And we’ll talk about those as we go through this section and the rest of the course. So I want you to keep that in mind as we go through. Just because you see a traffic spike doesn’t mean it’s a distributed denial of service attack. Now the other part of this is just because you see large amounts of bandwidth or traffic spikes being used doesn’t mean it was malicious to begin with. For example, if you’re running a website, your website can crash under the normal unexpected server load if that load increases because your website becomes popular too quickly.

Now I’ve seen this happen to a lot of smaller companies, but I’ve also seen this happen to big companies. A couple of years ago I was working at a security operations center and at the time United Airlines had reported they were having issues with their servers and they were having problems all over the US. Now when this happened, I don’t remember if they actually were under attack or not, but at the same time, a couple of hours later we started seeing the wallstreetjournal. com and it dropped offline. Now everyone started thinking, oh no, Wall Street Journal is being attacked. And they all thought there was a denial of service going on or a distributed denial of service. And when they went through and started looking at it, that isn’t what happened.

What happened was because the United Airlines had this system crash, which was some kind of a configuration issue, all the news outlets started talking about it and Wall Street Journal was one of those outlets. Because of that, people were going to Wall Street Journal to learn more about this issue with United because if it was really that they were hacked or attacked, that was going to be a huge deal because this was grounding flights all over America and so this became a big news story. Well, it became such a big news story that so many people were going to the wallstreetjournal. com at the same time that it actually took down their servers. And so it wasn’t a malicious denial of service attack or a malicious DDoS, but it was a huge traffic spike that was unexpected and their site became way too popular way too quickly and actually took them down for about an hour.

Now there’s actually a name for this effect and it’s called the slash dot effect. This is known as slash dotting as well. Now, this is causing a website to crash when a smaller website can become very popular very quickly due to exposure on some kind of a social sharing site like Slash Dot Reddit or Twitter or in the case of the Wall Street Journal at the time. It was being shown on things like Fox News and CNN, and people were going to that website to try to learn more information about it. Regardless, the effect was the same way too many legitimate users all going to the site at the same time, making it very popular very quickly and the server couldn’t handle it and it ended up crashing.

Now, this usually happens with smaller websites because their architecture isn’t designed in an elastic manner to handle an exceptionally high load. For instance, if my company became very popular overnight and we went from the couple of hundred thousand users that we have on a daily basis, up to a couple of million users on a daily basis, that could actually shut us down because we would grow too quickly. And so we are always looking at our load and expanding as needed based on our user loads. But we don’t have a server that can handle millions and millions of users because that would be prohibitively expensive for a small company like us.

And so we keep an eye on, we expand as we grow, but that can also be a downfall for us because if we had 10 million people show up at our site tomorrow, it would shut us down. And so we put different mitigations and protections in place to be able to help prevent us from being taken down by a huge surge of traffic from something like a DDoS attack. Now, those precautions won’t help us from legitimate traffic, so if we became popular overnight like that, we would still get taken down. So we have to keep an eye on that. And we’re constantly looking at our logs to make sure we grow with our user base. So that brings us to the concept of mitigation.

So how can we mitigate a DDoS attack? Well, there are five different ways we’re going to talk about. The first, you want to conduct real time log analysis to identify patterns of suspicious traffic and redirect it to a black hole or a sinkhole. Now we’ve talked about black holes and sinkholes previously in this course and the whole idea here is we have all this malicious traffic coming in from a DDoS. Instead of it trying to go into our network and process it, we just want to dump it to this black hole so we don’t have to respond to it and we don’t waste processing time on it. Next, we want to make sure that we’re using geolocation and it reputation data so we can redirect or ignore suspicious traffic. Let’s pretend I ran a restaurant here in the local area.

If I run a local restaurant and I have a website to take orders for that? Do I need to allow traffic from Russia and China and the Middle East and Europe and any place outside of my local area? Well, no. So in that case I can use geolocation and say, well, this person is trying to connect to me from California, and since California is way too far out of my delivery radius, they probably don’t really want to order food from me. So I can just drop that person because they’re not my real customer anyway. So that’s the idea of redirecting or ignoring any suspicious traffic using Geolocation or IP reputational data, people who have already been known to do bad things with that IP address, we can block them as well.

Now, the third thing we can do is we can aggressively close slower connections by reducing the timeouts on the affected servers. So let’s say my server was getting under load from this DDoS attack. One of the things I could do is actually go in there and change my timeouts, which by default is generally around two to three minutes. So if I have a three minute timeout or 180 seconds, I can actually reduce that maybe down to 60 seconds or 30 seconds or even 10 seconds. And that way if you can’t connect within 10 seconds, the connection will be closed. And if you’re a legitimate person, you’ll probably come back. If you are a distributed denial of service and you’re a bot, you might go away and go attack somebody else. And hopefully we can ride out that DDoS.

The fourth item is we want to use Caching and back end infrastructure to offload processing to other servers. If I have one server trying to do all of the load, it can quickly become overwhelmed. So instead we want to use things like Proxies and Caches, another back end infrastructure to help offload a lot of that processing to other servers, or even use a CDN where we can distribute that load across multiple servers. And that way we can suffer through that attack and keep serving our legitimate customers. And then our fifth and final one is we can utilize enterprise DDoS protection services such as things like Cloudflare or Alchemyi. These are commercial providers and they sit in front of your site.

So when you actually request to go to my site, it goes first to Cloudflare. Cloudfare checks you sees if you’re part of a DDoS, and if you are, they black hole and sync hole you. If you’re not, they redirect you into our site and you get your service. That’s the way these type of services work. Now, these services are commercial services. There is a monthly fee for them and depending on how big your site is and how much protection you need, you’ll pay more or less money. They are really good to use though, especially if you’re a smaller site or a large enterprise, because as a smaller site, you can’t afford to run your own DDoS protection. And as a larger site, you may not want to have the headache of it. And so you’d rather outsource this to the experts like Cloudflare and Akamai.

So with all that said about Distributed Denial of Service and traffic spikes, what is our goal as a company? Well, your goal as a company and a network defender should be to survive the DDoS attack. Most of the time, a DDoS is going to be short lived. They’re not sustained for long periods of time, for hours or days or weeks. Generally, they’re just a few minutes. As you saw earlier when I talked about buying a DDoS and DDoS for hire, they were giving you something like a six minute DDoS for that $35 per month. And so generally, you’re going to see these things last 510, 1520 minutes, and then they’ll move on. They’ll go on to another target or something else.

Now, in some cases, there have been sustained DDoS that have gone on for several hours or even as long as a day. But in general, you can just survive by getting through it. Mitigating what you can, closing down those connection cycles offloading things to other servers, utilizing other protections, using black holes and sinkholes and other things like that, to at least mitigate it down. Try to keep serving your users the best you can until the attack stops and you can go on with your business.