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

4. Beaconing (OBJ 4.3)

Beaconing. Now, when your computer gets infected with some kind of malware, it can have that malware run commands on it. But it’s only going to be a one way street. For an attacker to be able to have twoway control, it needs to reach back to a command and control server. One of the ways it does this is by using beaconing. Now beaconing is a means for a network node to advertise its presence and establish link with other nodes. So if we have somebody who’s been infected, once it’s been infected, it’s going to reach back to the central C Two server and say hey, I’ve been infected, I’m here now as part of your resource pool. Now, beaconing is not just a malicious thing though.

Beaconing can be used legitimately. For example, inside of your wireless access points there’s something called a beacon management frame and this is sent from a wireless access point to other wireless access points in the area to say hey, I’m here, I’m awake and I’m ready to accept traffic. Now malicious beaconing on the other hand, will usually take the form of a simple ping or a heartbeat to verify the bot is still alive inside of this botnet. Now, this beaconing can happen at regular intervals or it can happen at different times depending on how it’s configured. But the whole goal of beaconing is to send out a message from a victimized machine back to a C Two server to say hey, I’m here and I’m part of your botnet.

Now we’ll talk about the different communication channels used by this beaconing in just a little bit. So at this point we have a host, it’s been victimized and it’s beaconing out. Now the easiest thing for us to do would be to figure out where it’s beaten to and simply block that address. Right? Well because of that, attackers have started evolving their process. In the old days they would beacon to a common IP address or to a common domain name. But to make it more difficult for us to identify or block them as defenders, these type of malware are now changing their DNS names and their IP addresses all the time using things like DGA, domain generation algorithms and fastflux DNS.

So with all these changes happening, how can we detect this beaconing activity? Well, one of the most common ways is by capturing metadata about all those sessions that are being established or trying to make connections. And then using analysis we can correlate that into beaconing activity. Now, here’s a quick exam tip. For the exam you are likely going to see an example of beaconing. If they give you a log example and you see something happening as a beacon, they’re usually going to make it happen on a regular interval every 3 seconds, every 5 seconds, every 15 seconds, every day at midnight, something like that. Because that is traditional beaconing. But in the real world most attackers aren’t going to use the same time every single day.

Instead, they will jump around using some sort of an algorithm or they’ll switch up the IP or DNS names using DGA and Fast Lux DNS. Now, as I said earlier, there are some legitimate applications that will also perform beaconing. And this also makes it harder for us as defenders to identify what is malicious beaconing versus what is real beaconing. For example, a lot of legitimate applications like NTP servers, auto update and patching systems, and cluster services all use beaconing and heartbeats as a way for them to send out information and let other services know they are there and ready to support. So when you see something, you have to figure out is this malicious or is this something that’s authorized? And as a defender, learning what normal authorized behavior looks like within your network is key to start understanding what is malicious beaconing.

Because if it’s not something you’ve seen normally, it then becomes suspicious or malicious. Now, as I said earlier, the adversaries are constantly trying to redevelop their techniques so they don’t get caught. In the earlier days, they would use beaconing at consistent intervals. But to start avoiding detection, they started using DGAs and Fast Flux DNS and they started adding Jitter. Now, Jitter is an adversary’s use of a random delay to frustrate indicators based on regular connection attempt intervals. So if I used to see that this malware always connected at 03:15 A. m. , but now it may connect at 03:00 315 345 and it jumps around at different times using different delays.

That’s the idea of jitter. Now, this Jitter doesn’t have to be a long period of time. It could just be a couple of milliseconds or a couple of seconds in either direction. But even that is going to be enough to confuse some sensors. Another way adversaries try to hide their activity of beaconing is they will start using sparse delivery. This allows them to reduce their packet sizes and therefore they can hide within the noise of other network traffic. If you’re running a large network that’s sending out gigabytes of data every single day, will you notice just a handful of packets being sent out as a beacon? Maybe, or maybe not. It makes it a lot harder to find because it’s that noise inside that larger signal.

So now that we’ve talked a lot about beaconing in this lesson, you should understand what it is and why we use it. Because after all, a command and control server needs to be able to issue commands to its zombies as part of the botnet using some kind of a communication channel. Usually this is going to start out using a beacon and then it will be able to send out additional control signals in response to those beacons if they need to send out an attack. Essentially the beacon is just saying I’m here and I’m ready to receive orders. Then the command and control server needs to send information back to them. And how they do that is through various communication channels.

These channels include things like Internet Relay Chat or IRC, http and Https connections, domain Name System or DNS connections, social media websites, cloud services, and media and document files. Let’s talk about each of these as we go through the rest of this lesson. First, let’s talk about IRC, which is Internet Relay Chat. This is a group communication protocol with networks divided into discrete channels that are then used as individual forums by the clients to chat with each other. Now, IRC is basically the early version of chat. Think about it like Facebook Messenger or Discord or something like that. IRC was really popular back in the early 2000s. Essentially, you could log on to a different server and in that server there’d be lots of different chat rooms and you could go in and start talking on those.

Well, over time, people develop bots that could run these chatrooms and they could also be used as a command and control mechanism. Now, these days, most organizations don’t have a legitimate use for IRC, and because of that, most organizations will simply block IRC. This way, the use of IRC as a command and control channel is eliminated. And because of this, the use of IRC as a command and control channel has been on the decline for many years. So adversaries had to find another way. And that brings us to our second method, http and Https. Now, unlike IRC, every business has a need for web connections. You need to go to a website to pay your bills, you need to go to a website to sell things for your customers. You need to go to a website to set up your advertising campaigns.

All of that runs on Http or Https, which runs on either port 80 or port four four three. Now, these communications over these web protocols are a necessity in almost every organizational network. So you can’t just blank it and say, we’re not going to allow port 80 or port four four three traffic because you would shut down everything your business needs to run. So what can you do to prevent these from being used as a communications channel for these C two servers? Well, the best mitigation is to use an intercepting proxy at your network’s edge. Now, this is also known as break and inspect.

Essentially, you have a device at the edge of your network, and when somebody internals your network wants to connect to something like Gmail over secure connection, they would go instead of doing a connection between them and Gmail with an Https tunnel, they instead would connect from them to this intercepting proxy. And then the intercepting proxy makes a secure connection out to the Gmail server. This way you end up having a secure tunnel all the way across, but you’re essentially an authorized man in the middle sitting at that network edge. This allows your network defenders to analyze the traffic going in and out of your network within those Https connections, essentially being a man in the middle.

Our third type of communication channel that’s used heavily by C two networks is DNS, or the domain Name system. Now, most DNS traffic is not inspected or filtered in private organizational networks, so attackers have found DNS to be an effective command and control channel. Now, another reason this is an effective command and control channel is that you don’t actually have to have a direct connection to the outside network to be able to send out a signal. Instead, you can send it to your local DNS resolver. That local DNS resolver will then execute the lookup on the authoritative servers outside the organization, like on the Internet, and then they’ll receive the response with a control message.

Now, this allows attackers to send their commands in either a request or response query. So if I’m trying to do something as a beacon out, I can send it out as a malicious host sending out the request. And then if I want to send a command back, I can send that back as part of the response query. This way information can pass back and forth to that host and again, it usually will bypass any inspection and any filtering. So how do you know if it’s legitimate DNS traffic or if it’s an indicator, a compromise? Well, the first thing that might show that it’s an indicator of compromise is if you start seeing the same query being repeated several times when a bot is checking into a control server for more orders.

Essentially a normal DNS query will happen once. And you may not make that query again for several days. But if you see the same query being repeated every couple of hours or every day or two, that could be an indicator that it is a bot checking in. Another indicator could be if you start seeing commands sent within a request or response query. And when you see this, it’s usually because those requests and response queries will be longer and more complicated than normal. Now, one of the ways that attackers actually send out information as part of these request response is they’re actually going to send out more data inside that packet so they can send the commands they want to send.

So instead of just saying what is the address for Deon training? They may say what is the address for Dion training? And here’s all this other command and control information. So you’ll see a larger packet size or longer and more complicated requests. Now, with this second IOC though, one of the ways that they can evade detection is actually breaking up their control messages into several query chunks to help not trip the sensors. So instead of having this one really big DNS request, they can have that DNS request chopped into smaller packets. And by doing that, they will be able to evade detection. Again though, if you can take that traffic and put it back together, you can then see what the larger request was and see what malicious intent they had.

Our next category is social media websites. Sites like Facebook and Twitter and LinkedIn have all been vectors for command and control operations in the past. This is because as people have started blocking things like Internet Relay Chat, more people have moved to things like Facebook and Twitter and LinkedIn for messaging. Another reason the attackers use this is because by using these social media platforms, messaging functions, this allows the attacker to live off the land. They don’t have to create their own tools, they can just send messages through their APIs, and that way they don’t have to install anything and it makes it harder for you to detect them. For example, there was one case where a botnet was using LinkedIn as its command and control platform.

Essentially what would happen is these bots would check LinkedIn every day, and if they saw that the job position for a particular contact was changed. For instance, it went from the accounting department to the human resources department. That would be the signal to now do their attack payloads. And so that was the way they used this way to send out a command. It was very sneaky and it worked really well because a lot of companies trusted LinkedIn, and so when they saw something like a field like employment status or employment history or a status update, that could trigger some sort of action by this malware. Another example is Twitter.

There was another botnet out there that used hashtags as part of the command strings that they were sending to the bots. Essentially the way this worked is the bots on the victim machine would look at Twitter, and whenever they saw messages with a certain hashtag, they would then use that parse that message and use that as the way to receive their orders. Our fourth type of communication channel is cloud services. Cloud services are great for an attacker because they don’t have to own their own services and own their own servers. Instead, they can spin up virtual machines or use app based engines to be able to send out C two messages.

For example, attackers in the past have used Google’s app engine platform to send command and control messages through a hosted custom application within that platform. Others have used things like AWS Lambda to use those type of functions as well. And this way they don’t have to incur the cost of setting up their own servers, and they can use the cloud company’s reliable and scalable infrastructure to send out those messages to a very large audience of bots in their control. The final communication channel we need to talk about is metadata, which exists within media and document files.

Now, metadata is a set of data that describes information about other data. Now, for instance, if you’re looking at an MP3 file or a PNG file or a JPEG or an MP4 or anything, it could be audio or video or images. All of these have metadata embedded within those files. Now, the metadata within these files can hold attackers, command and control messages, too. And so when you actually send a message to that network, like, here is a PNG file, which is a graphic file as part of an email, the button could read that message, read the metadata off that PNG file, off that graphic file, and that would then tell them, execute XYZ attack method. This way, that metadata holds the C two messages, and it can get through your detection systems, because your detection systems probably aren’t looking inside the metadata of these different files.

5. Irregular P2P Communications (OBJ 4.3)

Irregular PeerToPeer communications. Now, on most networks, the predominant type of user traffic goes from a client to a server within most of our networks. So if you start seeing a lot of peer to peer communications, this could be an indicator, a compromise that you should look into further. Now, when we talk about irregular PeerToPeer or P two P communications, we’re really talking about an attack indicator where hosts within a network work establish connections over unauthorized ports or data transfers. One of the most common ways that this is done is by using SMB. This is the server message block and this is typically used within Windows networks to provide Windows file and printer sharing.

As we go through this lesson, I’m going to show you two examples of SMB, one of which is normal and authorized and one of which is irregular and an indicator of compromise. Now, as we do that, we are going to consider this network. Notice we have the server, which is ten 10 one and we have a client nominally written as ten 10 133. Now here inside the wireshark packet capture we can see that there is communication going from the source of ten 10 one to the destination of ten 10 133. This is going from the server to the client. Now, you should notice that the protocol is Spool SS which is a printer Spool protocol. You’ll also notice that it’s using Get printer response as it goes through and you look through these different lines, you can see this is normal traffic.

This traffic is what would be generated when the client 133 is connecting to the server one to be able to access a known file or print server. As we continue looking through these logs, you’ll then see that from the source, the server ten 10 one we are sending information to the client ten 10 133. This is a TCP segment and it begins sending some kind of file. Now, this file contains MZ, which is one of our magic signatures that we talked about back in forensics. What does MZ tell us? Well, this tells us it’s a Windows executable and in this particular case it’s actually a Windows driver that’s being downloaded from the server to the client.

Again, this is normal behavior when you connect to a new print server. If you don’t have the drivers, Windows will send it to you as a client and that way you can access that printer. As you can see going back and forth, all those purple highlights are part of this one stream which is that particular driver download. As I said, this is normal network traffic. Now, let’s take a look at something that might be a little more suspicious going back to our network diagram. Notice I still have my server ten one, dot zero, dot one, I have my client ten one, dot zero 133 and I have another client.

Ten dot one, dot zero, dot 248 and what’s going to make this suspicious is instead of having communication going from the server to the client, we are going to have communication between the two clients on an organizational network. There’s almost never a case where two clients need to talk to each other directly. Almost everything is going to go through a centralized server in a centralized organizational network. So let’s jump back into wireshark and take a look at what the suspicious communication between these two devices looks like. Now, again, here is communication happening between two PCs. Notice all of our numbers here are going from 249 to 133.

Notice all of our IP addresses here are going between two clients. Ten 10 249 and ten 10 133. This communication between two clients is something that is suspicious and we want to look into. So as I go through this packet capture, the first thing I notice here is this line. That is the fifth line down. It says going from the source of ten 10 249, the new client we just added to destination ten 10 133, the old client from the previous example. We have a message being sent that has net path cannibalization request now, what is this? This is essentially a packet that goes out as part of SMB and it tries to take the network path using the name and figure out what IP address or what client it is on the local network.

So essentially this is the beginning of  some sort of file sharing that’s going on. Now, you won’t know this, but this particular packet is actually indicative of a worm.In fact, the Configure Worm back in 2008 used this heavily. If you go back and actually learn about the Configure Worm, you’ll learn that the Net Path Cannibalization function was one of the things that was used as an attack vector and this actually was covered by Microsoft 867. So our newer systems aren’t vulnerable to this attack, but our older systems were. Now, for the Cysaplus exam, you don’t need to know Configure in detail and you wouldn’t be asked this particular packet capture to identify what was wrong.

But I’m just trying to show you the point of how this works in the real world. As you go through that packet capturing, you notice something that looks a little odd, like Net Packet Cannibalization request. You can look that up and then see if other people have noticed that too. And if you Google that, you would find pretty quickly that Conficker ties to that as a signature. So let’s go back to our packet capture again. There’s our net path canezation request. After we have that initial request, we’re going to see a three way handshake occur. So 249 sends out a Sin packet to 133. That client 133 responds back with a sync and then dot 249 is going to send back the Acknowledgment. So we now have that three way handshake. We now have a TCP connection between these two clients.

Again, something that would be a little suspicious in most corporate networks. After that, we see the client at dot 249 sending data over to the client at dot 133 and in this case, it’s pushing a lot of data and we put that all together. That actually comes together as a binary file. How do I know it’s a binary file? Again, I’ve highlighted the one line there and when you look inside, you see those two special characters MZ MZ again is that magic signature saying, this is a Windows binary. So what made this all unusual? Well, it was two clients talking to each other and then one client sending the other one direct information and that information was a binary.

So do I know this was malware? Not necessarily, but if I have a packet capture like this, I can actually extract that packet capture and get that binary file. Then I could go do some reverse analysis on it and determine if it was malicious, if it was malware and what that thing was particularly doing. That’s the idea of how you would attack this in the real world as a cybersecurity analyst. Now, the last type of irregular peer to peer communications we need to talk about is what happens on the local area network. Now, when you’re dealing with IP addresses, that happens on the local network, but it also happens across the Internet because that’s layer three. If we start talking at layer two, though, we’re going to be dealing with Mac addresses.

And so how can you spoof or poison Mac addresses? Well, if you’re dealing with ARP spoofing or ARP poisoning, this can occur when an attacker redirects an IP address to a Mac address that was not intended as its destination. This can cause irregular peer to peer communications as well. Now, to catch this type of thing, you are going to use an IDs. By using an intrusion detection system, you can identify suspicious traffic patterns caused by art poisoning and this art poisoning is going to generate far more ARP traffic than you normally would see. Now, if you want to look at this individually on a machine, you can inspect that local machine’s ARP cache as well and compare the Mac addresses to known values for server machines.

To do this, you would use ARPA as you can see here on the screen from your Windows command prompt. Simply type in ARPA and you’ll be able to see your interfaces. In this case, it’s a server with three different interface cards and all of the different physical addresses, those Mac addresses that are tied to the particular Internet addresses these machines have talked to. Now, if I compare these physical addresses, these Mac addresses, to the ones that I know are valid ones from my server environment, I can then know if there’s ARP poisoning going on or if I just have communications going across my network using layer two.