CS0-002: CompTIA CySA+ Certification Exam (CS0-002) Certification Video Training Course
CS0-002: CompTIA CySA+ Certification Exam (CS0-002) Certification Video Training Course includes 280 Lectures which proven in-depth knowledge on all key concepts of the exam. Pass your exam easily and learn everything you need with our CS0-002: CompTIA CySA+ Certification Exam (CS0-002) Certification Training Video Course.
Curriculum for CompTIA CySA+ CS0-002 Certification Video Training Course
CS0-002: CompTIA CySA+ Certification Exam (CS0-002) Certification Video Training Course Info:
The Complete Course from ExamCollection industry leading experts to help you prepare and provides the full 360 solution for self prep including CS0-002: CompTIA CySA+ Certification Exam (CS0-002) Certification Video Training Course, Practice Test Questions and Answers, Study Guide & Exam Dumps.
In this lesson, I'm going to use a tool known as Wireshark, which is a packet analyzer, to be able to pull apart some network traffic and show you the different layers of the OSI model. But for right now, I just want you to focus on how I'm pulling apart these different layers and the type of information I can get from Wireshark. Again, this is going to be further and more in depth than you need to know for the exam, but it's going to help you understand the OSI model a little bit better as we start putting these pieces together from this theory into something that's actually used on the network. So let's jump into the environment and take a look. All right. Welcome to Wireshark. Now the first thing we need to do is have a file to look at. So I have a couple of different packet captures, and I'm just going to open one up here, and it's going to be right here. This is an HTTP connection. So what I'm showing here on the screen is everything that happened for one computer to make a request from my computer to a server and back. So as you can see here, it starts at time zero. The source IP is my machine that sent the request, and the destination IP is the server I'm trying to go to. That's how we read these things. It's time source, destination, the protocol used in this case, TCP, and then the information that was sent. As you go through, you'll see there's a two-way conversation going back and forth between the two. And what you're seeing here is actually the session traffic that was captured from one host to one server. Now, as I scroll down a little further, you're going to see it goes down to 43 different line items that happened. It took 30 seconds total. and we're going to go in and look at some of this information. So let me go into this first packet. And here in the middle section, you'll see that we have frame one. This was the first frame. Now, going back to our OSI model, what is frame? Where do frames operate? Well, they operate at layer two. So I should expect to see some layer-two data in here. What types of things are layer two data? Well, things like Mac addresses. So if I open this up, you're going to see that the encapsulation type was Ethernet, which is a layer-two protocol. We can see the time it arrived, wecould see the time that it left. We can see what frame number it was and how long the frame was. We could see how much was captured and all the types of information there. Next, if I go into Ethernet 2, this again is part of Ethernet, which is Layer 2. And inside layer two, we can see our destination and our source. So this is our destination. This is the server I was trying to get to; its Mac address is below it, and underneath it we can see the source, which is the machine that I had that made the request. And it happened over IPV 4. And if I bring this down, you can actually see even further details. Now, the next thing I'm going to look at is IPV 4. When I start talking about IP, what are we talking about? Now? We're talking about layer three because we're talking about the Internet Protocol. This means that we're going to have source and destination IPS, as you can see here, highlighted in blue. And if I open that up, you'll see that this was version four. We can see the header length, and then we can actually dig into that packet. but again, way beyond the scope. The big thing we want to take away is layer two, which is Mac addresses. Layer three was IPS. Now when we go to layer four, we're going to be talking about: did we use TCP or UDP? In this case, we use TCP. So this is our Layer 4 of the OSI model. And as you can see, we're building up each of these layers. And all of that was one 162-bit packet that we captured. So the next one I'm going to do is the one that came back from the server to the host. So we sent the sin over, and now we have a synagogue back. As we look at that, we can see the same type of information in the same layout each time. You'll see that we have our frame, our layer two addresses, our IP addresses, and then our TCP protocol, layer four. So layer two; layer two; layer three; layer four. And we can go through the entire packet and look at each and every one of them. Now, if I want to figure out what was happening during this session, I can do that as well. So if I go in here, I can see that there was a Get request over HTTP. Now, HTTP is a protocol; it's an application. So this is actually a layer seven capture here. And if I open this up, I can see that they went to the server ethereal.com, that they were using Mozilla, which is Firefox, and that they came from this ethereal.com development, HTML webpage. And they clicked on the link to download HTML. And that's what we're asking for. We're asking for the web page's download HTML at this point. This is then acknowledged by the server and goes back and forth as they get more and more data. And eventually, we get that web page downloaded. In fact, if I right click on this, I can tell it to follow the stream, and I can see what that Web page looks like. Now this web page is being shown to be in HTML because that's how web pages are sent. But this is exactly what this person got when they went to that website, and we captured all that in this network packet. I could actually copy this, make it into an HTML file, and then load it up inside of Internet Explorer or Edge or Google Chrome or Firefox and be able to look at all of that. So I think that's enough of that packet. Let's take a look at another one and see if it looks similar. The next one I'm going to look at is this one here that says FTP. And what FTP is going to do is use the file transfer protocol. It's going to be very similar. You're going to see that we went from a source to a destination, and they went back and forth a whole bunch of different times. And in this case, it was a much longer stream. 561 different packets went through that were captured. So if I go back to the first one, you'll see that there was this acknowledgement, and they went back and forth. And we can go through here and see frames again; that's layer two, Ethernet. So, once again, we can see the source and destination as far as those Mac addresses are concerned. If we go down to the next one, we go up to layer three. We're now seeing the source and destination IP addresses. And when we get to layer four, we're able to see that this was a TCP session transmission control protocol. And so again, if I wanted to, I could right-click this and follow that stream. Now when I follow that stream, what am I going to see? I'm not going to see a pretty Web page because this was FTP traffic. Somebody was downloading a file. all of this. If I convert it back into its hexadecimal or binary format, let's go to Raw, for instance. I can copy this in and try to figure out what type of file it was and put that back together. That's what happens with network forensics and digital forensics, which go way beyond the scope of this particular course. But that's the idea here. You can capture everything going over the network into these PCAP files packet capture files), and you'll be able to open them inside of Wireshark to see what type of traffic is being used on your network. Really, you're going to be focused mostly on the screen, the source and the destination, the protocol, and even the ports. You can see here that it went from port 80, the Web port, to port 2727. The server then answered up from port 2727 back to port 80, and they went back and forth throughout this communication. Let's open up one more. We're going to open up TELNET. Now telnet is a way to remotely control a computer. Again, you're going to see that we have the time, the source, the destination, and the protocol, just like we did before. We have our synacdoche, which is that three-way handshake. And again down here, we have layer two, layer two, layer three, and layer four. Now in the protocol column you're going to see TCP, but you're also going to see this telnet data, and that is an application. So this is layer seven again, just like we saw with HTTP before. And if I go over here, I can see that layer—even now that it is added—and I get different information for that if I go through and right-click it and follow that stream. Let's see what we get this time. There we go. So what we're seeing is the person and their session when they try to connect to a Telnet server. So what you see in blue is what the server sent back. So when they connected, the server said, Hey, I'm an OpenBSD server login. What the person did was type F-A-K-E, which you can see is red. That's what the user sent to the server. And the blue is what the server displayed on a screen, which was fake. So their username was fake. Then it asked for their password, which the user typed in, "user." So their username is fake, and their password is user. At this point, they were able to log into the server and start running commands. They run the LS command, which, if you remember from a plus on a unit system, is going to list the contents of a directory. And then they did it again, LSA theywanted to see it going across the sideand you saw this is what came back. This is a list of directories. Then they tried to run aprogram s bin ping email@example.com. And that is showing that they tried to do a ping from this telnet server out to @yahoo.com, and they received this information back. Now we're seeing the entire conversation. We're seeing both halves. But if I wanted to see just what one person sent to the other, I could see it on the server side. It's a lot easier to read, right? But now I don't see that password. I don't see the commands that got sent over when I got here and switched over to the client side. This is what they typed in. I can see that they typed in User, which was their password, fake, which was their username, and then the commands, the list command, the list all, and the SBIN ping www.yahoo.com, and then exit. So you can see how this is useful and where we can start digging into this stuff. If you pursue a career with CompTIA and attend tent plus training, you will become very familiar with wireshark and will be able to dig in and grab this information from the wire. Now again. like I said. This video was a little bit beyond the scope of what you really need to know. But hopefully I've whet your appetite to the point where you're eager to learn more about wireshark and how you can use it both as a network technician and as a programmer. You need to be able to see where the breakdown of communication is. Whether it's layer two, Layer three. Layer four. Or layer seven. Or, from a defence standpoint, with cyber security analysts going through these packets and figuring out what the bad guys did on your system, because it will capture everything. both the server side and the client side. or if you're using it for Pentest. Furthermore, if you obtained this type of information, you now have access to that individual's username and password, which you can use as a follow-up in your account.
IP and DNS analysis. Now, many intrusions rely on C2 servers—or command and control servers—for the attack to download additional attack tools and exfiltrate data. As a result, analysing traffic for any access request to an external host is one of the specific areas of interest for a cyber security analyst. If you can identify these, you'll most likely be relying on an IP address and its DNS resolutions. If you subscribe to a service that provides reputation-based feeds, most of these are going to be based on IP and DNS as well. Now, in the old days, malware used to be configured to contact a specific static IP or DNS name as part of its code. So when that malware was downloaded and installed, it would call it from a specific static IP address or DNS server. When that malware was downloaded and installed, it would use a specific static IP or DNS name to contact it. Now, because of that, we would be able to develop what we call a known bad IP address. These are IP addresses or ranges of IP addresses that appear on one or more of our blacklists. And these blacklists were a way that we could basically play "Whack a Mole." A bad guy would start a new domain, we would find out it was bad, we would put it on the blacklist, and they would start another domain. and we'd keep doing this over and over. This is how reputation-based risk intelligence is done to create an IP or URL blacklist. We find something bad; we add it to the list. And so here you can see on my blacklist a thing called Bol.com BR. You'll notice that it's listed as a RAT because it is a remote access Trojan that's been associated with this particular DNS. Now, that's great, and that means that we can block this. But if they change their domain name, we're now going to have to go find that and block that too. As defenders, we try to outsmart the bad guys, but every time we find a way to block them, they find another way to get around it. And because we started using a lot of blacklists and blocking known bad IPS and known bad DNS, they started using what's known as domain generation algorithms to overcome those blacklists. Now, what is a domain generation algorithm? Well, a domain generation algorithm, or DGA, is a method used by malware to evade blacklists by generating domain names for command and control networks dynamically. Instead of having a static IP or a static name, they can create one and pick from a list of a lot of them, then keep moving through those until we block them all. And then they'll just create more. And they keep doing this over and over. Dynamically. Let's talk about how this works. There are five steps for an attacker to use. Now, the first thing an attacker is going to do is set up one or more dynamic DNS services. This allows them to be able to have domain names that can be automatically generated on the fly. When they do this, they'll sign up for a service using a fake payment or fake credentials, or they might use some host that really doesn't care if they're doing illicit activity. Once they do that, they'll move into step two. And this is where the malware code is going to implement the DGA. This DGA is then used to create a list of new domain names. Now, the way this works is that it's an algorithm, and it will use some kind of value to seed it. And then everybody who has that algorithm knows what that initial seed is and has the same key, essentially, to be able to use the same list. So if the piece of malware has it and their server has it, they both will have the same dynamically allocated names that they can jump to each time. The way this works is essentially like an algorithm that uses some kind of seed or random number or time-based basis or something like that. So for instance, we might have a start date that we're going to use, and that is going to be the seed. As we use that, it's going to create an output of a bunch of cryptic strings that basically have numbers and letters to make up domain names. This way, they're all randomized, and they won't already be on your block list. Then they move into the third step. At this point, a parallel DJ is going to be used to create the name records in the DDNS service. So now that we know what the malware is going to use, we also need the DDNS service to have it so those two can match up. And again, if they both use the same seed, they're going to have the same matching names. Then we go into Step Four. This is where the malware tries a selection of those domains that it created to connect to the C-2 server. This is in case the seed was off by a little bit. Hopefully they'll still match up, and they'll be able to make that connection. And then number five, the C-2 server, is going to communicate a new seed over time. So that way, they can change that DGA in case you reverse-engineered it and tried to block their attempts. This way, they can avoid being blocked and continue to do bad things. That's the idea with this DGA. It's this dynamic list that is constantly changing because it has this constantly changing architecture. This is often known as a fast flux network. Now, a fastflux network is a method used by malware to hide the presence of Two networks by continually changing the host IP addresses in the domain records using domain-generated algorithms Everything we discussed with DGA is essentially part of a fastflox network. So you may be wondering, as analysts, what can we do to detect a DGA? Well, there are a couple of giveaways that you're dealing with a DGA or a FastFlox network. Now, the first one that you'll see is if you start seeing a lot of call-outs from your systems to random IP addresses that look something like this. For instance, you see this random series on lettersandnumbers.com. That is a great sign that you are dealing with some sort of computer-generated label with some kind of constant to value ratio that just doesn't look right. Most people wouldn't buy a domain namelike a one Zwbr, 93, com. They would buy deontraining.com or CompTIA.org or something like that. So if you see things like this, it's usuallya sign that there's something malicious going on. The second thing that you can do to detect a DGA is if you start seeing a high rate of NX domain errors when you're resolving to DNS in your logs. This could be an indicator of a DGA. Now, what is an NX domain error? Well, have you ever gone to a website and got a message that looks like this? It says this site cannot be reached. The DNS probe was completed with the NX domain. That's an NX domain error. Essentially, you've tried looking up that domain name and can't figure it out. That's what it is. That's when you can't get the DNS resolver to resolve that DNS for you. And if you're using a dynamic DNS like this with a FastFlox network, they're often already moved off of that domain and onto another. And so you're going to get an NX domain error. Now, how do you mitigate these DGAs? Well, the best mitigation is to use a secure recursive DNS resolver. This is going to allow one trusted DNS server to communicate with several other trusted DNS servers to hunt down the IP address and return it to the client. So instead of going out to a generic DNS service to be able to get those domain names to IP resolutions, you should be using a trusted DNS server that uses recursive look up.If you do this and they keep track of what types of DNS are available, they will constantly block those for you and help protect your network.
Conduct packet analysis. In this lesson, I'm going to show you how to do some basic packet analysis using Wireshark. To do this, I'm going to launch a piece of malware on my system, and we're going to see how it spreads out over time. Now, to do this, I'm going to use two pieces of software. I'm going to use Proc Man to look at the processes and make sure the malware is actually launching. And then I'm really going to dig into the packet analysis using Wireshark so we can look at how those packets are going out and what IPS they are, so we can develop indicators of compromise. Let's go ahead and jump into the environment. And next, I want to open up Wireshark. So I'm going to click on the Windows icon, type in the word Wireshark, and open that program. Now, Wireshark is a great program. It's one that is used heavily in network analysis. And what we're going to use it for is to capture our network traffic when the malware launches. And that way we can see those beacons that happen every 3 minutes, see what data is being sent, or see who it's calling out to. And so I'm going to go ahead and hit the start button, which is this little shark fin, and it's going to start capturing data going into or out of our network. So now I'm going to go ahead and right-click on Trickster and run it as administrator, then go ahead and hit yes. So now Trickster is running; this should be copying U.exe into that directory and running it. And it did. And you can see that it's now showing up as a process. So I'm going to go ahead and move this over just a tad so we can see it. and we're going to go ahead and open up Wireshark a little bit better so we can see it a little more. Now, notice the time is different on Wireshark. They do it as a T plus whatever time is being used, whereas Process Man is doing it as the time of day. Now, if I want to correlate these two, I need to make them look the same. And so to do that, I'm going to go over here to Wireshark, and I'm going to change the way the time is displayed by going to view time display format and then choosing the time of day. This will allow us to correlate the two. So in the example here, we have the process starting at 143 and 29 seconds. So I'm going to go ahead and let this run just for a couple of minutes, and we're going to come back at 147. When I come back, we are going to see what traffic there is and if we can capture and see those three beacons and see if we can figure out what IP addresses they're calling out to from these processes. OK, we're going to go ahead and stop the capture here. So now that we've stopped the capture, let's go ahead and clear up this mess a little bit so we can see a little bit clearer what we're dealing with. Let's go ahead and first turn off our registry activity changes and our file system activity changes. This is going to leave us with just the network activity and just the processes. Now, the first process you can see here started at 143 29 and finished right here at 143 29. And the following one begins at 144, 28. So let's see if we can find these events. So as we start looking through this, we see at 143 that there was a Windows Update call out. Then we noticed this source returning to our machineover port 443, which is almost certainly connected to that. So we can skip that one. We'll go ahead and keep going a little bit further, and if we scroll down, we see that process number 144 is the next to start. So 144-2829 somewhere around there would be what we're looking for. And right here we see 144,29 that we had a standard query over DNS for an API, ipifi.org. This call out is going from our machine to the Google DNS server. Once it finds out what that IP address is, it starts making that call out from our computer over TCP/IP port 80 to this remote IP address. So we're going to note in our notes that this is a possible issue for us. This may be one of those IP addresses, and this IP Fi might be part of our malware. So we'll keep looking as we go down. So the next one we have, if we go down here on the right, is 145. It tries it again about a minute later. Now, in this 145 time frame, we're going to scroll down here and see what we can see at 145:28, which would be right around here. It again tries to make a connection, this time from 542-541-3664 to our machine. And from there, we see that it now makes this two-way connection with an acknowledgement and finishes up that handshake. So that is a communication issue between our machine and a remote server that we're going to want to look into. Now, if we do this, we can go follow the TCP stream and see what was said. In this case, there's not much to it—it's just to keep a live connection. There was a standard request to basically get a webpage and an IP address back. Now, the reason why this particular piece of malware is a piece of training malware, And so what we're seeing here is that it's going to this website and saying, "Hey, what's my IP address?" This local IP address is the local IP address that you're finding here from this machine during this session. So as you can see, we can see those callouts, and we can start making a list of the IP addresses it calls to.If I left this running for a long period of time, like ten, fifteen, or twenty minutes, you would see that it actually calls out over several different IP addresses as it tries to make its way to some command and control server. Because maybe we are blocking this one because we already knew it was bad, but it can then move to the next one. That's the idea here. And what we're trying to figure out is where these TCP connections are going, so we can develop these indicators of compromise and block them in our firewall. So even if we are infected with Stage One malware, it can't go and get Stage Two malware and start installing it.
Download Free CompTIA CySA+ CS0-002 Practice Test Questions, CompTIA CySA+ CS0-002 Exam Dumps
|CompTIA.test-king.CS0-002.v2023-11-05.by.theo.162q.vce||2||6.75 MB||Nov 12, 2023|
|CompTIA.braindumps.CS0-002.v2020-06-26.by.albie.25q.vce||3||244.66 KB||Oct 05, 2020|
Similar CompTIA Video Courses
Only Registered Members Can Download VCE Files or View Training Courses
Please fill out your email address below in order to Download VCE files or view Training Courses. Registration is Free and Easy - you simply need to provide an email address.
Log into your ExamCollection Account
Please Log In to download VCE file or view Training Course
Only registered Examcollection.com members can download vce files or view training courses.
SPECIAL OFFER: GET 10% OFF
Pass your Exam with ExamCollection's PREMIUM files!
SPECIAL OFFER: GET 10% OFF
Use Discount Code:
A confirmation link was sent to your e-mail.
Please check your mailbox for a message from firstname.lastname@example.org and follow the directions.
Download Free Demo of VCE Exam Simulator
Experience Avanset VCE Exam Simulator for yourself.
Simply submit your e-mail address below to get started with our interactive software demo of your free trial.